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Foreword 

This is a “transitional” version of the Rails: A Student Manual series, basically a direct translation of the 
old Rails 3.0 version into Rails 4.0. 

I could go on and explain why I made this manual instead of going directly to Rails 4.1 but I won’t bother. 
It will all boil down to the advice “do not use this manual for learning ” anyway. Treat this book as a 
writing practice that I decided to put out there online. 


Foreword to the Rails 3.0 version 

Computer Science teachers have it easy. Every time a new semester rolls in, they can simply reuse the 
material they’ve been using for years. 

As a teacher of a quickly evolving web framework, I do not have that luxury. 

As I write this, less than 24 hours has passed since the Rails Core team released the new version of Ruby 
on Rails: version 3.1.0. This means that I now have to update my student manual (i.e. this document) for 
upcoming classes to use this new version. Having done that before when we moved from Rails 2.3. to Rails 
3.0, 1 know how much of this document will be changed: sections will be gutted, swaths of code rewritten, 
and at least one new chapter would be added. 

And, yet again, I will not be paid a single cent for those updates. 

So instead of just letting this nearly obsolete document go to waste, I’ve decided to give it away for free. 


Code 

Code examples in this book are available at the following locations: 

• https://github.com/bryanbibat/rasm40code 1 - up to date code, written under Ubuntu 14.04 


License 

This book is copyright ©2014 by Bryan Bibat 2 . 

This work is licensed under the Creative Commons Attribution-NonCommercial 3.0 Unported License. 
To view a copy of this license, visit http://creativecommons.Org/licenses/by-nc/3.0/ 3 or send a letter to 
Creative Commons, 444 Castro Street, Suite 900, Mountain View, California, 94041, USA 

tl;dr: I’m cool with you modifying this document in order to better suit your needs e.g. turning Aling Nena 
into Farmer Bob, changing the Chrome/Firefox screenshots to Safari, using Swahili instead of Tagalog in 
the I18n section, etc. What isn’t ok is modifying this work in order to sell it, profiting off it while leaving 
this poor third-word developer to starve. =( 


1 https://github.com/bryanbibat/rasm40code 

2 http://www.bry anbibat.net/ 

3 http://creativecommons.org/licenses/by-nc/3.0/ 


Introduction to Ruby on Rails 

What is Ruby on Rails? 


Ruby on Rails 4 (often shortened to Rails or RoR) is a web development framework written in the Ruby 5 
programming language. Some popular examples of websites using Rails are Hulu 6 , BaseCamp 7 , and 
GitHub 8 . 

The biggest draw for Rails is the radical improvement in productivity compared to other web application 
platforms. Rails makes programming web applications easier by making several assumptions about what 
every developer needs to get started. This allows you to write less code while accomplishing more 
than many other languages and frameworks. Longtime Rails developers also report that it makes web 
application development more fun. 

Prerequisites of this Course 

This course assumes that the student is an experienced web developer and is familiar with: 

1. Basic web development: HTML, CSS, and JavaScript 

2. Web application development: HTTP, server-side scripting 

3. Object-Oriented Programming 

4. SQL and RDBMS concepts 

This course will focus on the Rails part of Ruby on Rails. This means that knowing the Ruby programming 
language is not a prerequisite of this course, nor will we dwell too much on the language. We will only 
discuss just enough Ruby as we go along the lessons - don’t worry; you can still do a lot in Ruby on Rails 
even with limited Ruby knowledge. 

Learning Ruby beforehand will help, of course. Some suggested sites for learning Ruby: 

• TryRuby.org 9 

• Learn Ruby The Hard Way 10 


4 http ://ruby onrails . org/ 

5 http://www.ruby- lang.org/ 

6 http://www.hulu.com/ 

7 http://basecamphq.com/ 

8 http ://github . com/ 

9 http://tryruby.org/ 

1 °http ://ruby .learncodethehardway . org/ 
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Required Software 

For this training course, we will be using the following software: 


• Ruby 2.1, but 1.9.3 above is ok 

• Ruby on Rails 4.0.5 

• RSpec 2.14 

• SQLite 3 or MySQL 5 



Installing Ruby on Rails 

The Apple Macintosh is the platform of choice for developing Ruby on Rails apps. However, the reality is 
that most of us struggling developers don’t have the money to spare in buying expensive Apple computers. 

This section will cover how to install a Ruby on Rails development environment on Windows and Linux. 

Installing on Windows 

Download and use the latest Railslnstaller 11 from the linked website. This installer already includes Ruby 
1.9.3, SQLite 3 as well as Git and essential tools for building native extensions in Windows. 

The latest stable version, 2.2.3, is using Rails 3.2 so you will have to manually call RubyGems, Ruby’s 
package manager in order to get the Rails version that we need. Open a terminal via the Command Prompt 
with Ruby and Rails shortcut and run the following command: 

C:\Sites> gem install rails -v= 4.0.5 

This will also install documentation around the latter half of the installation and that may take some time 
to finish. If you’re in a hurry, you can safely skip that part by telling RubyGems to skip documentation: 


C:\Sites> gem install rails -v=4.0.5 --no-ri --no-rdoc 

RailsFTW 

A smaller alternative to Railslnstaller would be RailsFTW 12 . This installer does not contain Git 13 and build 
tools 14 , but it’s smaller, uses the faster Ruby 2.0, doesn’t require internet access, and includes MySQL 
support. 

If you wish to use RailsFTW, download v0.14 15 as it contains Rails 4.0.5. 


Installing on Linux 

Installing RVM 

There are several ways of installing Ruby in Linux. Here we will be using Ruby Version Manager 16 (RVM) 
which will handle the installation for us. RVM requires Git, curl and essential build tools, while Ruby and 
SQLite have their own requirements which RVM will install for us when we install Ruby. That said, let’s 
install RVM’s prerequisites: 

1 *http ://railsinstaller . org/ 

12 http://railsftw.bry anbibat.net/ 

1 3 http ://code .google . com/p/msy sgit/ 

14 http://rubyinstaller.org/add-ons/devkit/ 

15 http://files.bry anbibat.net/rails-ftw-vO. 14- 2.0. 0-4.0. 5.exe 
16 http://rvm.io/ 
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$ sudo apt-get install curl build-essential git-core 

(For the sake of simplicity, we’ll assume you’re using Ubuntu for the entire Installing on Linux section.) 
After installing the required packages, we install RVM using the following command: 

$ \curl -sSL https://get.rvm.io | bash -s stable 

Open a new terminal window to startup RVM and run the following command to install the latest version 
of Ruby 2.1: 

$ rvm install 2.1 


After RVM installs Ruby and SQLite 3, you must now tell RVM to set the default Ruby version to 2.1 
rather than the default system Ruby. (Note you may need to set your terminal to “Run command as a 
login shell” for the command below to work.) 

$ rvm 2.1 --default 

Installing Rails 

Installing Rails is a matter of calling RubyGems, Ruby’s package manager. Thanks to RVM, we do not 
need to have admin rights to install Rails: 

$ gem install rails -v=4.0.5 --no-ri --no-rdoc 

This is the same command we used to update Railslnstaller to Rails 4.0.5. 

(We don’t need to install SQLite for Ruby because Rails does this already when we create a new SQLite 
app.) 

Installing NodeJS 

At version 3.1, Rails introduced the Asset Pipeline which make serving asset files (e.g. images, CSS, JS, 
etc) more reliably in addition to providing a means to insert preprocessing (e.g. minifying, compression) 
for these files. Because of this, a new Rails 4.0 app will by default require a JavaScript runtime installed 
along with Rails. 

Linux users can install a JavaScript runtime in the form of NodeJS 17 : 

$ sudo apt-get install nodejs 

Windows XP/Vista/7 users already have a JavaScript runtime as part of the OS so they don’t need to 
install anything aside from Railslnstaller or RailsFTW. Windows 8’s JavaScript runtime, on the other 
hand, is incompatible with Rails so you also need to install NodeJS from the linked site above. 


17 http://nodejs.org/ 
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Linux on Windows 

Compared to Mac OS X and Linux, certain Rails commands are noticeably slower in Windows. This is 
more pronounced once you start using RSpec. 

If your computer is fairly new (i.e. multi-core processor and 2 or more GB of RAM are cheap nowadays), 
you might want to consider running Linux in a virtual machine; Ruby can run faster in Linux even though 
it’s just a virtual machine. 

There are free virtualization software available on the Internet. The most popular ones are Oracle 
VirtualBox 18 and VMware Player 19 . 

As for the Linux distribution, we recommend Ubuntu 20 so that you could just follow the installation 
instructions above for installing Ruby on Rails. 


IDE 

ASP.NET and Java EE developers might be surprised to know that the most popular “IDE” for Ruby on 
Rails is TextMate, a relatively simple text editor on the Mac. As we shall see later, there are some reasons 
why Ruby on Rails does not require full-fledged IDEs for development. 

Any text editor will do fine for Ruby on Rails development. For Windows, Redcar 21 and Sublime Text 2 22 
are good choices because they’re free (as of this writing), has Ruby syntax highlighting, and can handle 
Linux and Mac line breaks properly (unlike Notepad). Linux users can use vim or emacs; both editors have 
steep learning curves but they can be more productive than IDEs once you get the hang of them. 

If you still insist on using an IDE, there’s Aptana RadRails 23 and JetBrains RubyMine 24 . 


API Documentation 


This document is meant to be more of a training manual than a reference manual. It will not contain 
detailed descriptions of each function available in Ruby on Rails, instead, you will have to refer to the 
official API documentation for those details. 

Apart from the official Rails API docs 25 , there are other alternative Ruby and Rails documentation sites 
that provide aditional features apart from basic lookup e.g. ApiDock 26 and Omni ref 27 . 


18 http://www.virtualbox.org/ 

1 9 http ://www.vmware . com/products/player/ 

20 http://www.ubuntu.com/ 

21 http://redcareditor.com/ 

22 http://www.sublimetext.com/2 

23 http ://aptana. com/ 

24 http ://■ www. j etbrains. com/ruby/ 

25 http ://api. ruby onrails . org / 
26 http://apidock.com/ 

27 https ://www. omniref. com/ 


Web Application in 5 Minutes (or Less) 

Aling Nena's Request 


Imagine one month from now you’re walking down your street. Passing by your neighborhood sari-sari 
store, its owner, Aling Nena, calls you over. 

“You know how to make websites, right?” 

Now, you’ve known Aling Nena since childhood so you know that she’s not your typical sari-sari store 
owner. Instead of a TV, she’s got a desktop computer with broadband connection to occupy herself while 
waiting for customers. It’s not uncommon to see her browsing social networking sites or chatting with 
her children and grandchildren abroad whenever you buy something from her store. 

“I’d like to have a website for tracking the debts of my customers. I’m using a spreadsheet now, but it’s 
getting more and more of a hassle to open the spreadsheet file when I could just open a new tab in my 
browser. Think you could do it? I’ll give you a week-long supply of cornik for your trouble. . .” 

Once you heard the last part, you immediately accepted the request. I mean, who could turn down such 
an irresistible offer like a week-long supply of cornik? 

And so Aling Nena enumerated what she wants the website to do: 

• It must be able to list all of the her customers’ debts. 

• It must be able to create a new debt record. 

• It must be able to retrieve and display the details of a single debt. 

• It must be able to update the details of a debt. 

• It must be able to delete a debt record. 

Also, a debt record should have the following details: 

• name - the name of the customer with the debt 

• item - contains the items bought under credit; can be much longer than the name field 

• amount - the amount the customer owes Aling Nena; should allow cents. 

“Sure, no problem,” you replied after seeing the requirements. 

You take out your laptop from your bag, booted it up, and then entered the following commands in the 
command line: 

$ rails new al ingnena-app 
$ cd al ingnena-app 

$ rails generate scaffold debt name: string item: text amount : decimal 
$ rake db: migrate 
$ rails server 
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After running these commands, you open your browser to http: //local host: 3000/debts and showed 
the results to Aling Nena. 


1! 

TPirnl 

A 



|«- c 1 

© localhost: 3000/debts & 

" 


Listing debts 


Name Item Amount 
New Debt 


Clicking the New Debt Link will open the New Debt page. 




— n 


tM AlingnenaApp 

HBQk + 


C © localhost: 3000/debts/new 

New debt 

Name 


☆ * 



Amount 


178.50 


Create Debt 


Back 


Clicking Create will save the new debt. 
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Finally, clicking the Back link will return you to the List Debts page. Each existing record has Show, Edit, 
and Destroy links so that Aling Nena can view, update, and delete the records, respectively. 


raJQIaL 

Alir.gr e n gAp p VO 

^ CO localhost: 3000/debts 


☆ 

1 * 

Listing debts 




Name Item 

Amount 



1 Mang Bhoy 5 bottles of beer and assorted snacks 178.5 

Show Edit Destrov 


Jun-jun softdrinks 

20.0 

Show Edit Destrov 


Manang Betty sugar and some spices 

15.0 

Show Edit Destrov 


New Debt 





If you’re like Aling Nena, who’s staring speechlessly at the screen amazed at how fast you created the 
web application, you might be wondering, “That’s it?!?” 

Yes, that’s all you need to do to create a working Ruby on Rails application. In the next few sections, we 
shall discuss what just happened here. 

MySQL notes 

This training course assumes you’re using SQLite. If you’re using MySQL, you must first install the 
MySQL gem. In Ubuntu, this can be done via 

$ sudo apt-get install 1 ibmysqlcl ient-dev 
$ gem install mysql2 

Then you must specify that you’re using MySQL at the rails command with the -d option.You will also 
have to modify the database settings at conf ig/database . yml to point to the correct server and provide 
the correct credentials. You may refer to TODO for more details about database settings. 

Also, SQLite does not require you to create a new database schema when you run rake db: migrate. 

For MySQL, you can create the schema via Rails through the rake db : create command (as long as the 
user has been granted rights to create the database): 


$ rails new alingnena-app -d mysql 
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$ cd al ingnena-app 

$ rails generate scaffold debt name: string item: text amount : decimal 
$ rake db: create 
$ rake db: migrate 
$ rails server 


rails destroy 

Made a typo when using the rails generate command? Simply re-run the command replacing 
generate with destroy to delete all of the new files generated by that command. For example: 

$ rails destroy scaffold debt 


Creating the Application 

The first command tells Rails to create the directory structure and the files needed by the application. 
$ rails new al ingnena-app 


In this case, we named our application “al ingnena-app” and the following directory structure was created 
by rails: 


< > 1% Home alingnena-app 



b = 


Places 






© Recent 

■ 

■ 

■ 

■ 


1% Home 

app 

bin 

config 

db 


[■Desktop 



[= . 



D Documents 

■ 

■ 

■ 

Mi 


❖ Downloads 

lib 

log 

public 

test 


<J9 Music 



1# Thr* 

[rarr*| 


Q Pictures 

■ 

■ 

requi 



H Videos 

tmp 

vendor 

conHg.ru 

Gemfile 


© Trash 

[sen 

iisn 

|= Rf- 



Devices 

spe 

Irani 1 

i This 



® Computer 

Gemfile.lock 

Rake file 

README.rdoc 



Network 







Here’s a brief explanation for each item in the application folder (copied from the Rails Guides): 
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File/Folder Purpose 


app/ 

bin/ 

conf ig/ 
conf ig . ru 
db/ 

Gemfile Gemfile. lock 


lib/ 
log/ 
publ ic/ 
Rakef i le 


README. rdoc 

test/ 

tmp/ 

vendor/ 


Contains the controllers, models, views, helpers, mailers and assets for your 
application. You’ll focus on this folder for the remainder of this guide. 

Contains the rails script that starts your app and can contain other scripts you use to 
deploy or run your application. 

Configure your application’s routes, database, and more. 

Rack configuration for Rack based servers used to start the application. 

Contains your current database schema, as well as the database migrations. 

These files allow you to specify what gem dependencies are needed for your Rails 
application. These files are used by the Bundler gem. For more information about 
Bundler, see the Bundler website 28 . 

Extended modules for your application. 

Application log files. 

The only folder seen by the world as-is. Contains static files and compiled assets. 
This file locates and loads tasks that can be run from the command line. The task 
definitions are defined throughout the components of Rails. Rather than changing 
Rakefile, you should add your own tasks by adding files to the lib/tasks directory of 
your application. 

This is a brief instruction manual for your application. You should edit this file to tell 
others what your application does, how to set it up, and so on. 

Unit tests, fixtures, and other test apparatus. These are covered in Testing Rails 
Applications 29 . 

Temporary files (like cache, pid, and session files). 

A place for all third-party code. In a typical Rails application this includes vendored 
gems. 


At this point, we can already test if the application is setup properly by skipping the 3rd and 4th commands 
above i.e.: 


$ cd al ingnena-app 
$ rails server 

Opening your browser to http : / /local host : 3000/ will result in the following screen: 


28 http://gembundler.com 

29 testing.html 
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□ Ruby on Rails: Welcome aboard 



^ [& localhost:3000 


T C| 13 ^ Google Q <0? 


fl 


Welcome aboard 

You’re riding Ruby on Rails! 

About vour application’s environment 


Getting started 

Here's how to get rolling: 


Browse the 
documentation 

Rails Guides 
Rails API 
Ruby core 

Ruby standard library 


1. Use rails generate to create your 
models and controllers 

To see all available options, run it without parameters. 


2. Set up a root route to replace this page 

Ybu're seeing this page because you're running in 
development mode and you haven't set a root route yet. 

Routes are set up in config/routes.rb. 


3. Configure your database 

If you're not using SQLite (the default), edit 
config/database.yml with your username and password. 


If you’ve read the table above thoroughly (which I bet you didn ’t), you’ll realize that http : // 1 oca 1 host : 3000/ 
points to the public/ folder. In many web servers, the default HTML file returned by the server is 
index . html when you don’t specify the page. Rails, however, provides a default page when publ ic/ index . html 
is not found. You can verify this by putting a dummy index . html file in that folder. 

The welcome screen above is basically “home page” of the application. Later in this course, we shall discuss 
how to replace this page with a dynamic one. 

Generating the Scaffolding 

The next command generates everything needed for the debt application: the code for setting up the 
database tables, the code to handle the user’s actions, the web pages displayed to the user, etc. The 
command is a bit complicated so let’s dissect the command part-by-part: 

$ rails generate scaffold debt name: string item: text amount : decimal 

• rails generate - tells ruby to run the “generate” script 

• scaffold - tells the generate script to create a scaffolding. Like its construction counterpart, a 
scaffold is just a temporary structure where we start building our applications. 

• debt - the name of this part of the application. In the next chapter, we shall discuss the concept 
ofConvention Over Configuration and this is a prime example of that approach. Take note of how 
Ruby on Rails uses this single word as aconvention throughout the application: 

- “Debts” will become the name of the resource i.e. the table in the database. 
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- The model class that will handle the database operations for that resource will be named 
“Debt.” 

- The debt handling application will be accessed via http://localhost/debts . 

- “Debts” will be the name of the debt handling application as we shall later see in the Action 
Controllers. 

- name:string item:text amount : decimal - these define the fields for the Debts table. As you 
may have guessed, this part tells the script that the table will have a “name” field containing 
strings, an “item” field containing text (longer than a string), and an “amount” field containing 
a decimal value. Convention Over Configuration is also active here, by looking at the type of 
field, the script knows that “name” should use an < input type="text"> element in the web 
page while “item” would use <textarea>. 


The command generates the following files: 


File 

app/models/debt . rb 

db/migrate/2014xxxxxxxxxx_create_debts . rb 

app/views/debts/index . html . erb 
app/views/debts/index . json . jbui lder 
app/views/debts/show . html . erb 
app/views/debts/show . json .jbui lder 
app/views/debts/new . html . erb 
app/views/debts/edit . html . erb 
app/views/debts/_form . html . erb 

app/assets/stylesheets/debts . css . scss 

app/assets/stylesheets/scaf fold . css . scss 

app/assets/javascr ipts/debts . js . coffee 

app/control lers/debts_control ler . rb 
test/functional/debts_control ler_test . rb 
app/helpers/debts_helper . rb 
conf ig/routes . rb 
test/fixtures/debts . yml 
app/helpers/debts_helper . rb 
test/unit/helpers/debts_helper_test . rb 


Purpose 

The Debt model. The Model-View-Controller architecture 
will be discussed in the next chapter. 

Migration to create the debts table in your database (your 
name will include a different timestamp). 

A view to display an index of all debts. 

A view to display an index of all debts in JSON format. 

A view to display a single debt. 

A view to display a single debt in JSON format. 

A view to create a new debt. 

A view to edit an existing debt. 

A partial to control the overall look and feel of the form 
used in edit and new views. 

Cascading style sheet (in SCSS) with styles for the debts 
views. 

Cascading style sheet (in SCSS) to make the scaffolded 
views look better. 

JavaScript (in CoffeeScript) describing behavior of the debts 
views. 

The Debts controller. 

Functional testing harness for the debts controller. 

Flelper functions to be used from the debts views. 

Edited to include routing information for debts. 

Dummy debts for use in testing. 

Unit testing harness for the debts model. 

Unit testing harness for the debts helper. 


One thing to note here is that generated scaffolding only has one flow: 
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List Debts 


Edit Debt 



While this might be sufficient for simple applications, this flow is rarely used in typical real world 
applications. Being a temporary structure, it’s very likely that you will modify the scaffolding to the 
point that the finished product is very different from where you started. That said, many experienced 
Ruby on Rails developers avoid scaffolding entirely, preferring to write all or most of their source code 
from scratch. 

Setting Up the Database 

The final command deals with setting up the database: 

$ rake db: migrate 

Database migrations are Ruby classes that are designed to make it simple to create and modify database 
tables. The rake command above applies all migrations not yet applied to the target database. 

In our example, the command above applies the migration that was part of the generated scaffolding, 
2014xxxxxxxxxx_create_debts . rb. Let’s take a look at the contents of that file: 
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class CreateDebts < ActiveRecord :: Migration 

def change 

create_table : debts do I t I 
t. string :name 
t . text : item 
t. decimal : amount 

t . timestamps 

end 

end 

end 

This is an example of a real working Ruby code. You might notice how high-level Ruby code is; even if 
this is the first Ruby code you’ve seen in your life, it doesn’t take much effort to see that this file defines 
(“def”) the “change” behavior wherein it creates a table named “debt” along with the fields we’ve specified 
before. Later in the course, we shall discuss how to do other things with migrations like modifying tables 
and rolling back changes. 

Frequently Asked Questions 

Did Ruby on Rails compile the generated code? 

No. Ruby is an interpreted language like JavaScript and so it isn’t compiled. You could even edit your 
code while the server is running - you would immediately see the changes the next time you access the 
updated application. 

Can I use a different web server aside from the bundled one? 

For most cases, the built in web server (WEBrick) is sufficient for development. You can just switch to 
more full fledged servers like Apache and nginx once you deploy the live version of your application. 

However, if you feel WEBrick is somewhat slow, you can also try using Thin as a replacement. To install 
Thin, add the following line at the end of your Gemf i le: 

gem 'thin' 

Then install it by running bundle i nsta 1 1 . 

Once installed, starting the server with rails server will now use Thin instead of WEBrick. 

$ rails s 
=> Booting Thin 

=> Rails 4.0.5 application starting in development on http://0. 0.0. 0:3000 

=> Run 'rails server -h' for more startup options 

=> Ctrl-C to shutdown server 

Thin web server (vl.6.2 codename Doc Brown) 

Maximum connections set to 1024 
Listening on 0.0.0.0:3000, CTRL+C to stop 


Some commands start with rails, others with rake. What’s the difference? 
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• rails - the command used to create an application and run Rails scripts. 

• rake - similar to C’s “make” (rake = Ruby + make), it’s a tool that allows more complicated scripts 
for tasks like database migration and running unit tests. 



Modifying the Application 

Aling Nena's Follow-Up 

After being astounded by how fast you build the program, Aling Nena suddenly remembered something. 

“Can you add another field where I can put remarks like ‘This was partially paid’ or ‘He promised to pay 
for it before the end of March’ and so on?” 

This is a common sight in software development. Software (being soft) are often subject to changes. 
Fortunately for us, Rails provides ways to easily handle changes in the requirements. 

Looking at this change request, it is clear that we need to do two things: 

1. update the table in the database to add the new field, and 

2. update our application to accommodate the new field. 

Rails Migrations 

As mentioned in the previous chapter, Rails uses migrations to simplify database tasks. Before we move 
on to how to use migrations to meet our task (i.e. add a new field to the database), let’s discuss why there 
are migrations in Rails. 

In other more traditional software development platforms, when you want to add a new field to the 
database, you’ll need to write an SQL statement like 

ALTER TABLE debts ADD remarks VARCHAR(255) ; 

and give it to someone who is responsible for maintaining the databases in order for it to be applied to 
all those databases. Now, granted SQL isn’t that hard to learn, and having a DBA managing the database 
changes can be a somewhat efficient way of handling the data, but there are some reasons why migrations 
have the upper hand over this approach. 

The first benefit of migrations is that it simplifies the whole database management process. Rails includes 
scripts to apply changes to different databases allowing any developer (or even a batch script) to deploy 
changes without the need for a database administrator. 

Rails migrations also have a limited set of data types which are internally converted to the appropriate 
data type for different kinds of databases. In other words, unlike with manual SQL wherein you have to 
take into account the differences between Oracle, MySQL, IBM DB2, etc., you don’t need to worry about 
these things in migrations. 

Another benefit of migrations is that it provides ways to migrate to a certain snapshot of the database 
structure. As there are timestamps in the file name, anyone can use a command to choose which timestamp 
to roll back to. This is useful when you’re testing old builds which require an older version of database 
schema to work. (We will discuss this command in a later chapter.) 


Modifying the Application 


17 


Generating the Migration 

As migrations have timestamps in their file names, it may not be practical to create them from scratch, 
with the developer defining the current timestamp in the file name. A better approach would be to use 
the built in migration generator which creates an empty migration file with a proper timestamp. 

The format of the command to generate the migration is: 

$ rails generate migration [MigrationName] 

MigrationName can be in camel case or lower case separated by underscores (Rails converts the former 
to the latter in the actual file name, and the latter to the former in the class name). Here is a sample file 
produced by the command: 

class MigrationName < ActiveRecord : Migration 
def change 

end 

end 

The generated file, as mentioned above, is empty, and it is up to the developer to define the changes to be 
applied to the database using migration commands. 

Rails provides a shortcut for creating migrations that add or remove columns from tables. When you name 
your migrations as Add [Col umnName] To [Tab leName] or Remove [ColumnName] From [TableName] followed 
by a series of field_name:data_type pairs, Rails will automatically create the add column or remove 
column statements, respectively, in the migration. For example, we can perform the required change to 
our application without having full knowledge of the migration commands: 

$ rails generate migration AddRemarksToDebt remarks: text 

This command will create the following migration file 30 : 

class AddRemarksToDebt < ActiveRecord :: Migration 

def change 

add_column : debts, : remarks, :text 

end 

end 

Rails supports the following data types: 


3 °https://github.com/bryanbibat/rasm40code/commit/336ffd958bl430db2al0bl94bcl2f609cfc084f2#diff-0 
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Data Type 

: string 
: text 
: integer 
: float 
: decimal 
: datetime 
: timestamp 
: time 
: date 
: binary 
: boolean 


Description 

A relatively short string field. 

An unbounded string field, used for longer text. 

A number with no fractional part. 

A floating point number. May or may not be precise depending on the database. 
A number with a fractional part. Always precise. 

A date and time field. 

Same as datetime, but with fractional seconds. 

A time field. 

A date field. 

Field for storing binary data e.g. image files. 

A field that stores either true or false. 


We’ll discuss the other possible migration options in a later chapter. For now, let us just stick with add_- 
column. 


Ruby Corner 

From this point onwards, you will see small sections like this one explaining bits and pieces about Ruby. 
The alternative to this is that we dedicate an entire chapter of the course just to study Ruby. 

We chose the latter approach for the sake of efficiency; not only are we not distracting ourselves too 
much away from our primary goal (i.e. learn Ruby on Rails), explaining Ruby’s features in context of 
actual working code allows for better understanding and retention. 


Ruby Corner - Interactive Ruby 

One way of writing and running ruby programs is to put the code inside a . rb file then execute it with 
“ruby [ruby file]”. The other (simpler) method is to write and run the code under a Ruby shell. 

There are two shells that you can use in Rails: irb, which is the interactive ruby shell that comes with 
Ruby, and the Rails script “rails console”, which creates an environment based on the current Rails 
app, allowing you to test the classes inside. 

Since Ruby is an interpreted scripting language, not only can you run single statements inside the shells, 
you can also declare functions and classes as well. For example: 

$ irb 

irb( main ): 001 :0> def hello(x) 
irb(main) : 002 : 1 > "hello #{x}" 
irb(main) : 003 : 1 > end 
=> nil 

i r b ( ma i n ) : 004 : 0 > he 1 1 o ( " wor Id") 

=> "hello world" 


Shortcut Corner 
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There are shortcut aliases for certainrails commands. You would probably be familiar with them from 
the message displayed when you enter an incorrect rails command: 

$ rails serve Error: Command not recognized Usage: rails COMMAND [ARCS] The most common rails 
commands are: generate Generate new code (short-cut alias: “g”) console Start the Rails console (short- 
cut alias: “c”) server Start the Rails server (short-cut alias: “s”) ... 

The shortcut aliases can be used in place of their full values. For example “rails c” is equivalent to 
“rails console”. 


Ruby Corner - Dynamic Typing and Variables 

Ruby has your typical programming language data types e.g. String, Integer, Float, etc. Being a 
dynamically typed object oriented programming language, you don’t have to worry about creating and 
assigning the correct data type to the correct variable. Everything is an object and thus can be assigned 
to any variable. 

A variable name in Ruby must begin with an underscore (\_) or lower-case letter followed by any 
combination of alphanumeric characters and underscores. Variable names are case sensitive in Ruby. 
As with other programming languages, you cannot use reserved words as variable names. The standard 
for naming variables is to use all lower-case letters and separate words with underscores. 

You can assign values to variables using the = operator. 

x = 10 
x = "20" 

You can create variables anywhere in a ruby program. Location simply dictates the scope of thevariable, 
as all basic variables are local variables (they’re only available in their scope). 

Constants are variables that start with a capital letter. They can only be assigned a value once. 

Other variations of the variable exist, and later we will discuss how instance variables are defined in 
Ruby. 


Ruby Corner - Operators 

The precedence of operators in Ruby are described by the following table: 
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Method? 

Operator 

Description 

Yes 

[ ] [ ] = 

Element reference, element set 

Yes 

** 

Exponentiation (raise to the power) 

Yes 

! ~ + - 

Not, complement, unary plus and minus 
(method names for the last two are +@ anc 
-§) 

Yes 

* / % 

Multiply, divide, and modulo 

Yes 

+ - 

Addition and subtraction 

Yes 

> > < < 

Right and left bitwise shift 

Yes 

& 

Bitwise ‘AND’ 

Yes 

* 1 

Bitwise exclusive ‘OR’ and regular ‘OR’ 

Yes 

<=<>>= 

Comparison operators 

Yes 

<=> == === != =~ ! iv 

Equality and pattern match operators ( ! = 
and ! ~ may not be defined as methods) 


&& 
1 1 

Logical ‘AND’ 
Logical ‘OR’ 



Range (inclusive and exclusive) 


? ; 

Ternary if-then-else 


= %= /= -= += |= &= >>= <<= *= &&= 
| |= **= 

Assignment 


defined? 

Check if specified symbol defined 


not 

Logical negation 


or and 

Logical composition 


if unless while until 

Expression modifiers 


begin end 

Block expression 


As you can see, these operators should be familiar with non-Ruby save for the few Ruby-specific ones. 

Studying the use of these operators is left to the reader. Here are some points to note, though: 

• The parenthesis takes precedence over all operators. 

• The operators with a “Yes” in the “Method?” column are implemented as methods, and may be 
overridden. 

• Logical operators (and, or, &&, I I ) use short-circuit evaluation. Also, every expression evaluates 
to true except for nil and false. 

• Unlike C and C-based languages, there are no ++ and - - operators in Ruby. Use += 1 and -= 1 
instead. 


Ruby Corner - Basic Data Types 

Ruby is a fully object-oriented programming language so it doesn’t have primitive data types per se. 
Everything in Ruby is an object, for example, the number literals have methods and you can see stuff 
like 20 . even?( ) in a typical Ruby code. 

Rails does have some classes that you might call basic data types considering the convenience of their 
use: 

• Numbers - integers are Fixnum objects by default (i.e. 100 is parsed as a Fixnum), when they get 
too large they are converted to Bignum, an infinite precision integer. Decimal values are Float 
objects, though if you want arbitrary-precision (e.g. you’re calculating monetary values where 
floating point errors are a big no-no), you can convert them to BigDecimal. 

• Strings - Like in JavaScript, strings can be enclosed with either single-quotes or double-quotes. 
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When using double-quotes, you can insert values inside the string using string interpolation with 
#{expression}. For example: {linenos=off,lang=”ruby”} “l + 2 = #{1 + 2}” # this will return “l + 2 
= 3” 

• Boolean - true and false are the boolean objects in Ruby 

• Null - nil represents the null object in Ruby 


Ruby Corner - Methods 

A method in Ruby looks like the following: 

def add(a, b) 

return a + b 
end 

We won’t get too much into detail about the structure of a method declaration so we’ll just stick 
tothe basics: a method declaration starts withdef, followed by a method name, followed by parameters 
enclosed in a parenthesis. The block is then closed with anend.You can usereturn to return a value for 
the method. If you don’t, Ruby uses the value of the last lineof the method as the return value. This 
would allow us to shorten that method into: 

def add(a, b) 
a + b 

end 

The standard for naming methods is the same as local variables, all lower-case with words separated by 
underscores. 

As with most object oriented programming languages, declaring a method inside a class makes it 
apublicly accessible instance method. It can also be declared outside a class i.e. used in a script. 

Let’s take a look again at our new migration: 

class AddRemarksToDebt < ActiveRecord :: Migration 
def change 

add_column :debts, :remarks, : text 

end 

end 

The method change is declared inside the class AddRemarksToDebt. The method is an instance method 
of the class i.e. the system will instantiate it and call it like migration ,change( ). 

Previously, migration methods like change were class method, and as such were prefixed with self, (one 
of a few ways to declare class methods). Back then, the system would call AddRemarksToDebt . change( ) 
at the time of migration instead. 

Speaking of method calls, you call Ruby methods pretty much the same way as methods in other 
programming languages. For example, calling: 


puts add(3, 3) 
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would print out 6. 

Non-Ruby programmers might be surprised to know that puts is also a method (it prints a string to the 
standard output followed by a new line). In Ruby, enclosingmethod arguments in parenthesis is optional 
as long as there is no ambiguity. For example, this statement is legal: 

puts add 3, 3 

There is no standard regarding when to use parenthesis in method calls. Programmers usually just use 
their discretion: when the code reads clearly without parenthesis, they don’t use parenthesis. When 
enclosing a method call makes the distinction between nested methods clear, they use parenthesis. You 
will see a lot of these types of decisions throughout rails. For example, migrations don’t use parenthesis 
in the add_column and remove_column: 

add_column :debts, :remarks, : text 


Ruby Corner - Symbols 

One peculiar data type confuses a lot of new Ruby programmers, though: the Symbol. 

Symbols look like variables prefixed by a colon (: ). A good example would be from our migration above: 

add_column idebts, :remarks, : text 

: debts, : remarks, and :text are all symbols. 

One easy way of explaining what they are to non-Ruby programmers is that they are just like global 
String constants. You can’t change their value (i.e. :text is always :text), and you can use them in 
many places where strings are used (e.g. as a key to a hash). 
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Ruby Corner - Classes and Modules 

Classes in Ruby are declared with the class keyword followed by the class name and ended with an end 
keyword. The class name must begin with an upper-case letter just like constants. 

class AddRemarksToDebt < ActiveRecord :: Migration 
end 

The standard for naming classes is to use CamelCase. 

Due to the scripting-like nature of Ruby, classes can be defined anywhere in the program just like local 
variables and methods. 

The initialize method acts as the constructor for Ruby classes. To instantiate a class, you can use the 
new method. Every methods inside a class is, by default, public. We will discuss instance variables and 
private methods later on. 

You can define a class’s superclass by using the < operator in the class definition. In the above case, 
AddRemarksToDebt is a subclass of Migration. 

The ActiveRecord in the above example is a module. Modules are like classes except that they can’t be 
instantiated and they can’t be subclassed. The declaration is the same, with module replacing the class 
keyword. 

Modules have two uses. First is for defining namespaces. In the example above, the Migration class is 
under the ActiveRecord module. You can imagine that the code for the two is like this: 

module ActiveRecord 
class Migration 

end 

end 

Another use for modules is to create mixins , a sort of multiple inheritance approach in Ruby. Since you 
can define methods inside a module and the linking process in Ruby consists of bringing together code 
from various files, mixins are classes which include the methods of other modules. For example: 

module Modulel 

def hello 

puts "hello" 

end 

end 

module Module2 

def world 

puts "world" 

end 

end 

class HelloWorld 
include Modulel 
include Module2 


def initialize 
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hel lo 
world 

end 

end 

When you call Hel loWorld . new, the constructor will call the methods taken from the two modules. 


An Introduction to the Model-View-Controller Architecture 

With the database side of the task out of the way, we can now move on to modifying the application itself. 
But before that, let’s take some time to understand how various components are organized in Rails via 
the Model-View-Controller (MVC) architecture. 

MVC was originally created in the 1980s as a pattern to follow when creating graphical user interfaces 
in Smalltalk. It found a resurgence in the early 2000s when it became apparent that this model was also 
applicable for web applications. 

In MVC, systems are divided into three parts: the model, the view and the controller. A typical flow 
through an MVC system would be as follows: 



1. User (in the form of a browser here) sends a request to the Controller 

2. Controller interacts with the Model 

3. Controller invokes the View 

4. View renders the information sent to the User. 

Putting this in context of Rails applications, when a browser visits a Rails web page, it goes through the 
following steps: 
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1. Browser requests a page from the server e.g. http://my.url/books/123 

2. Routing finds the Books Controller 

3. Controller interacts with the Model 

4. Controller invokes the View 

5. View renders the page to be sent to the browser 

Why use MVC? 

In the early days of the web (and even up to now), many web applications were written with all of the 
processing logic (business processing, routing, rendering) concentrated in a single location. This approach 
didn’t scale well for some reasons: 

• Maintenance was hard. Lack of structure meant that the dependencies between modules aren’t clear. 
Changing one part of the system might affect another part of the system without a programmer 
knowing it. 

• Debugging was hard. As all of the processing logic were contained in single files, a programmer 
hunting for the code that caused a bug would have to scan through a lot of code which has nothing 
to do with the bug itself before finding it. 

MVC addresses these problems. First off, the structure provides a degree of isolation between modules. 
Sure, changing a Model might still affect a lot of programs in the system, but at least the extent of the 
changes can be easily predicted. 

When you encounter a bug in a Rails application, you also have a better idea where to look for the problem. 
This diagram shows where the source code for the MVC components are located: 
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MVC best practices 

There are many best practices when it comes to using MVC. We’ll list down a few here, but we’ll also 
have to use an analogy to make it clearer to someone who hasn’t used MVC before. 

Our analogy would be a restaurant analogy. 

In a fine dining restaurant, you have your chefs (Models) which prepares the food for the customers 
(Views). There are also waiters (Controllers) that facilitate communication between the customers and 
the chefs. 

Chefs are expected to do all of the preparing, cooking, and plate presentation on the dishes. Aside from 
very trivial changes to the dishes (e.g. offering to add pepper to the soup) the waiters do not do anything to 
the food. Here is the first best practice for MVC: Models should do most of the processing, controllers 
should only focus on the routing. Similarly: If you find your controllers doing a lot of processing, 
find a way to move those logic to the model. This is usually called the “fat model, skinny controller” 
approach. 

Some dishes are so complicated that a single chef isn’t enough to handle it. In this case, it’s alright for 
multiple chefs to work on a single dish without having to go through the waiter. In other words, Related 
models can communicate with each other before passing their result to the controller. 

As for our customers, they should not talk directly to the chef and vice versa i.e. Views should not 
directly call models directly, and vice versa. However, this does not mean that the customers should 
be mindless. It’s up to them how to eat their food. In MVC terms, Processing logic is allowed in views, 
as long as it’s related to the view or presentation. 

Now that we understand the basic underpinnings of Rails, we now have a basic idea about what to modify 
in our system to meet the demands of the current task. 

Modifying the Model 

...or not. 

Veterans of other MVC frameworks might think that we need to modify some model related files to reflect 
the changes to the database. In some frameworks, we might need to add additional fields to certain classes. 
In other frameworks, we might need to modify certain XML files to include the new fields. 

Fortunately for Ruby on Rails, we don’t need to do any of those. 
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At the heart of Rails’ model components isActive Record, a Ruby package that handles the database related 
portion of Rails. Not only does Active Record provide functions for saving and retrieving data, it also 
provides other features that help simplify database management e.g. migration commands. 

To make development easier, Active Record directly checks the database schema to determine the fields 
of the model. This is made possible thanks to Convention over Configuration (database fields and model 
fields should be named the same) and Ruby’s dynamic nature (methods can be defined on the fly). In 
short, there is no need to change any part of the model when the database is changed - the change is 
automatically applied to the model and we could access theremarks field via ©debt . remarks. 

Of course, if we would need to add some field validation (e.g. mandatory checking, field length checking), 
we will need to modify the app/models/debt . rb. We will leave that topic for a later chapter. 

Modifying the Controller? 

By looking at the flow of the MVC model, you could see that adding a new field to our screen wouldn’t 
affect our controller: the routing of data is still the same after the change. 

However, adding a new field means we need to tweak the security settings in the controller to 
allow the controller to recognize it as a valid data input field. Change the third to the last line of 
app/control lers/debts_control ler . rb 31 : 


# Never trust parameters from the scary internet, only allow the white list through. 
def debt_params 

params . r c quir c ( : d e bt) . p c rmit( : nam e , — : it e m, — : amount) 

params require( : debt) , permit( : name, :item, : amount, : remarks) 
end 

end 


(By the way, the Ruby package that handles the controller for Rails is ActionController.) 

Modifying the View 

In the end, the only files we have to modify to include the new field is in the View, namely the four view 
files for Listing, Show, Create, and Edit. 

Insert the highlighted lines into app/ views/debts/ index.html .erb 32 : 

<hl>Listing debts</hl> 

<table> 

<tr> 

<th>Name</th> 

<th> Item</th> 

<th>Amount</th> 

<th> Remarks </th> 

<th> </th> 

<th> </th> 


31 https://github.com/bryanbibat/rasm40code/commit/a7c04e8b03ef523b711039fa4239435705e55558#diff-0 

32 https://github.com/bryanbibat/rasm40code/commit/a7c04e8b03ef523b711039fa4239435705e55558#diff-2 


Modifying the Application 


28 


<th> </th> 

</tr> 

<% ©debts. each do I debt I %> 

<tr> 

<td><%= debt . name %></td> 

<td > <%- debt. item £></td> 

<td > <%- debt . amount ^></td> 

<td> <%= debt remarks ^></td> 

<td><%= link_to 'Show', debt ^></td> 


Insert the highlighted lines into app/views/debts/show . html . erb 33 : 


<p> 

<strong>Amount : </strong> 
<%= ©debt. amount %> 

</p> 


<p> 

<strong>Remarks : </strong> 
<%= @debt . remarks %> 

</p> 


And finally, insert the highlighted lines into app/views/debts/\_form . html . erb 34 : 


<div class=" field" > 

<%= f. label : amount X><br> 
<%= f.text_field : amount %> 
</div> 

<div class="field"> 

<%= f. label : remarks %><br> 
<%= f.text_area : remarks %> 
</div> 

<div class="actions" > 


(Just as in the controller, the Ruby package that handles the view for Rails is ActionView.) 

33 https://github.com/bryanbibat/rasm40code/commit/a7c04e8b03ef523b711039fa4239435705e55558#diff-3 

34 https://github.com/bryanbibat/rasm40code/commit/a7c04e8b03ef523b711039fa4239435705e55558#diff-l 


Rails Applications Without Scaffold (part 1: 
Show and List) 


Pleased with how you handled the “Debt Records” program, Aling Nena has decided to hire you part time 
in order to computerize every aspect of her shop. 

Part of this job is to create a system to to handle the inventory of her shop’s goods. So for your next task, 
you need to create a program which maintains the list of products in her shop. 

This is a good time to discuss how to create a program from scratch i.e. without using therails generate 
scaffold script. 

The Plan 

The Product Maintenance program has 6 different parts: 

• User must be able to create a product record 

• User must be able to view the product record 

• User must be able to view a list of product records 

• User must be able to modify a product record 

• User must be able to delete a product record 

• User must be able to search for a product record 

In addition to this, we also need to setup the database for a Products table with the appropriate fields. In 
the end, we have 7 tasks to be done in the following order: 

1. Create the migration for Product 

2. Program the “Show Product” module 

3. Program the “List Products” module 

4. Program the “Delete Product” module 

5. Program the “Search Products” module 

6. Program the “Create Product” module 

7. Program the “Edit Product” module 

We’ve chosen this order of tasks so that the tasks are done in increasing coding complexity. So without 
further ado, let’s proceed with the first 2 tasks. 

Viewing a Record 

First up is the “Show Product” module, a page that displays the details of a certain Product record. We’ve 
combined this step with the “generate migration” step because we’re going to generate the migration along 
the way anyway. 

The basic flow for showing a single record from the user is as follows: 
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1. User provides the id of the record via the URL 

2. Program retrieves the record from database 

3. Program renders the retrieved data into a web page and sends it to the user 
In this lesson, we shall see how these steps are coded in Rails. 

Generating a Model and adding test data 

Instead of usingrails generate scaffold, we shall use rails generate model, a script that only generates 
the migration and the model for the specified model and fields. The syntax of the latter is the same as the 
former: 

$ rails generate model Product name: string description : text cost: decimal stock : integer 

We need to modify the generated migration to add some dummy data for our new screen. Add the 
highlighted lines to the migration file 35 : 

class CreateProducts < ActiveRecord Migration 
def self. change 

create_table : products do I t I 
t. string :name 
t.text description 
t. decimal :cost 
t. integer : stock 

t . timestamps 

end 

Product . create :name => "test product 1", description => "test description 1", 

:cost => 1.11, :stock => 10 
Product . create :name => "test product 2", 

description => "<b>test description 2</b>", 

:cost => 2.22, :stock => 20 

end 

end 

Generating a Controller and View Page Templates 

A controller action (not to be confused with Action Controller ) is a public instance method inside 
the controller class that processes requests from the user. We can generate controller actions and their 
corresponding views with the use of therails generate controller script. The syntax for the script is: 

rails generate controller control ler_name action [action2 action3 ...] 


35 https://github.com/bryanbibat/rasm40code/commit/08cef231c36eca7541a7dll800cb0e5dd35e5bc8#diff-l 
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Rails Conventions 

The name of the controller must be the plural form of the model. 

The name of the action for showing the details of a single model is show. 

By default, after processing a controller action, Rails will render the view file named [action_- 
name] . html . erb in the folder app/views/ [control ler_name] /. So for the show action of the products 
controller, it will render app/views/products/show . html . erb. 


Given the conventions, here’s the script for generating our controller and view: 

$ rails generate controller products show 

This script will create the controller app/control lers/products_control ler . rb: 

class ProductsController < Appl icationControl ler 
def show 

end 

end 

and also the view app/views/products/show . html . erb: 


<hl >Products#show</hl > 

<p>Find me in app/views/products/show . html . erb</p> 

You can now test the new controller and view by running the server (rails server) and going to 
http : //local host : 3000/products/show . The following page should be displayed (you may have to 
restart the server through rails server): 


mu&L 

AlingnenaApp \Q 


#» C © localhost:3000/products/show/ 

☆ * 

Products#show 

Find me in app/views/products/show.html.erb 



The show action in the controller automatically refers to the show . html . erb file even without additional 
code as mentioned in the Rails conventions above. 

We still have 2 problems at this point: 


1. We still haven’t displayed the details of the record. 
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2. The format of the URL is different from the convention used by the code generated fromrails 
generate scaffold i.e. http : //localhost : 3000/products/l. 

The 2nd problem is simpler and deals with routing so let’s tackle that first. 

Routing 

Routing deals with how different pages and controllers are linked to each other in a system. In Rails, there 
is a central configuration file that determines the available routes in the system. At first glance this may 
look like a violation of the Convention over Configuration mantra, but as we shall see much later, there 
are ways to let this routing file use convention to reduce the amount of configuration needed. 

For this tutorial, we shall do away with the convention-related shortcuts so that you could understand 
how rails routes pages together. Take a look at the generated con fig/routes . rb file: 

A1 ingnenaApp : . Appl ication . routes . draw do 
get "products/show" 
resources : debts 

# The priority is based upon order of creation: first created -> highest priority. 

# See how all your routes lay out with "rake routes". 

# You can have the root of your site routed with "root" 

# root ' welcome# index' 

# Example of regular route: 

# get ' products/ : id ' => ' catalog#view ' 

# Example of named route that can be invoked with purchase_url ( id : product. id) 

# get ' products/ : id/purchase ’ => ' catalog#purchase ' , as: : purchase 

# Example resource route (maps HTTP verbs to controller actions automatically): 

# resources : products 


# Example resource route with options: 

# resources : products do 

# member do 
get 'short ' 
post 'toggle' 

end 


collection do 
get 'sold' 
end 
end 


# Example resource route with sub-resources : 

# resources : products do 

# resources : comments, : sales 
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* resource : seller 

# end 


# Example resource route with more complex sub-resources : 

# resources : products do 

# resources : comments 

# resources : sales do 

# get 'recent', on: : collection 

# end 

# end 


* Example resource route with concerns : 

* concern : toggleable do 

* post 'toggle' 

* end 

* resources : posts, concerns: : toggleable 

* resources : photos, concerns: : toggleable 

* Example resource route within a namespace : 

* namespace : admin do 

* # Directs /admin/products/* to Admin :: ProductsControl ler 

* # (app/control lers/admin/products_control ler . rb) 

* resources : products 

* end 

end 


Ruby Corner - Comments 

Single line comments in Ruby begin with a hash sign (#). 

Multi-line comments in Ruby are rare, but FYI, they are enclosed between =begin and =end. 


It can be a daunting file at first glance, but removing all of the comments, we can see that it’s a pretty 
simple file: 

AlingnenaApp : Application routes. draw do 
get "products/show" 

resources : debts 

end 

Before we proceed with creating our routes, let’s discuss first the idea behind the routing conventions in 
Rails: REST. 

Representational State Transfer (REST) 

Representational State Transfer (REST) is a scheme for communicating between clients and servers using 
HTTP. It was promoted as a stateless means of communication in a 2000 paper by Roy Fielding. 
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We will not go into detail about REST, and instead, we shall only focus on the parts that are relevant to 
us in Rails. In that regard, there are two main points about REST that we should know: 

1. All resources are uniquely identified by a URL. For example, a product record can be identified with 
the following URL: 

http : //my . url/products/1 

In contrast, an item done in a non-REST framework might look like this 
http : //my . url/view_product.do 

In this case, all product records share the same URL and are differentiated only based on the user’s 
state, either via session or cookie. 

2. Actions done on resources are defined by the HTTP verb of the request. Here are some examples: 

• GET http : //my . url/products - get (a list of) all products 

• POST http: //my . url/products - post a new product to the list of products 

• GET http : //my . url/products/1 - get the product with the id of 1 

• PUT http : //my . ur 1 /products/1 - put an updated product with the id of 1 to the database 

• DELETEhttp : //my . ur 1 /products/1 - delete a product with the id of 1 

The 5 HTTP commands in the 2nd point above are, by convention, how resources should be handled in 
Rails. 

Now that we know the convention for the URL ( http://localhost:3000/products/l ) and the convention 
for the controller action (method must be namedshow for viewing records), we can now move on to 
connecting the two in our con fig/routes . rb. 

Configuring Routing in routes.rb 

Going back to the diagram in MVC, all browser requests to our Rails server goes to the routing component 
of the controller first. At this point, Rails checks entries inside the routes . rb file from top to bottom to 
see which controller and action to call. 

We want to add a new “route” to the show action in theproducts controller and we can do this using the 
get declaration inside the routing block. The basic syntax of get is: 

get(path_string, options_hash) 

When Rails processes a GET request then reaches a get line in the routes . rb file, it first checks the path_- 
string if it matches the request’s URL. The Ruby symbols in the path_string are placeholders and may 
match any part of the URL. When these symbols are matched to a part of the URL, they are converted 
into parameters inside aparams hash. (See Ruby Corner - Hash below for a discussion on hashes) 

For example, if you added a catch-all get routing handler like: 
get ' : control ler(/ : action(/ : id( . : format) ) ) ' 

and then you called http : //localhost : 3000/products/show/l , Rails would match this request with the 
route get ' :controller(/:action(/: id( . : format))) ' producing the following parameters: 
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params = { : controller => 'products', : action => 'show', : id => 1 } 

Based on this params hash, Rails can now route the request to the controller and action we created earlier. 

We don’t need to define the controller and : action symbols within a route. We can specify them as 
defaults using the => form of match: 

get (' products/show ' => ' products#show ' ) 

Opening http ://localhost: 3000/products/show will make Rails use the controller and action defined 
in the right side, in this case, the show action of the products controller. 

At this point, we can create a route 36 that matches Rails’s conventions on “show record” pages: 

AlingnenaApp : Application routes draw do 
resources : debts 

get( ' products/ : id ' => ' products#show ' ) 
end 

Going to http://localhost:3000/products/l will create the following parameters: 
params = { controller => 'products', : action => 'show', : id => 1 } 

As you can see, while the whole URL is matched by the path (‘products/: id’) only the : id part is 
converted to a parameter. The rest of the parameters for controller and action are provided as defaults at 
the right of the => symbol. 

Testing http : //localhost : 3000/products/l , we now see the following page: 


■ ■ 

AlingnenaApp \Q 


^ CO localhost:3000/products/1 

☆ * 

Products#show 

Find me in app/views/products/show.html.erb 



We’ve completed the routing setup. We can now proceed to building the rest of the “Show Record” 
program. 


Ruby Corner - Hash 

Ruby has a built-in collection for storing key-value pairs, the hash. Ruby is a dynamically typed language 
so you can use any data type for the keys and values. 

Hashes can be initialized by a pair of curly braces. Initial key-value pairs can be added using the 


3s https://github.com/bryanbibat/rasm40code/commit/588d3f9al579ccc9ffla66ff3199c9c3e56e4e29 


Rails Applications Without Scaffold (part 1: Show and List) 


36 


hashrocket symbol (“=>”). For example: 
my_hash = { } 

another_hash = { : key => "value", 1 => "a number" } 

One way of visualizing hashes is to think of them as lookup tables. Here’s one for another_hash: 

key value 

: key “value” 

1 “a number” 

Values are retrieved and set with the use of square brackets ([ ] ): 

puts another_hash [ : key] 
my_hash [ "test" ] = : value 

Please refer to the API docs for other Hash methods. 


Ruby Shortcuts 

Since version 1.9, Ruby Hashes now support a JSON-like format aside from the original hashrocket 
syntax. For example: 

yet_another_hash = { : foo => "bar", :model => "resource" } 

Is the same as: 

yet_another_hash = { foo: "bar", model: "resource" } 

This only works for hashes that use simple symbols as keys (ie. we can’t use it in our get ( 'products/:id. . . 
example above), but you will have many opportunities to use this syntax because most of the time you 
are going to use simple symbols as keys. 


Ruby Shortcuts 

The curly braces are optional when the hash is the last argument in a method call. Ruby treats the 
following method calls 

get( control ler/ : action/ : id ' , { : defaults => { : id => 1 } } ) 
get( control ler/ : action/ : id ' , idefaults => { : id => 1 } ) 

as both having only 2 arguments. We can remove the parenthesis to further reduce the characters in the 
method call: 
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get control ler/ : action/ : id 1 2 , idefaults => { : id => 1 } 


From this point on, we shall use this form for get. 


Putting it all together: Retrieving a Record 

To recall, our basic flow for this program is: 


1. User provides the id of the record via the URL - already done 

2. Program retrieves the record from database 

3. Program renders the retrieved data into a web page and sends it to the user 
Steps 2 and 3 can be better illustrated by the MVC diagram we had before for Rails: 




Display 

Book 

View 


Active 

Record 

Model 



Retrieve Record in the Controller using Model 

According to the diagram, retrieving the data has 3 steps: 



1. After the routing dispatches the request to the controller, the controller calls the model to retrieve 
the data. 

2. The model retrieves the data from the database. 
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3. The model sends the data back to the controller. 

The first half of the first step has already been done. All requests to ' products/ : id ' are now dispatched to 
the Products controller’s show method. All that is left to do is to actually utilize the model to retrieve data 
from the database. We can do the remaining steps by inserting 37 the following line to theshow method: 

class ProductsController < Appl icationControl ler 

def show 

@product = Product . find(params [: id] ) 
end 
end 

Retrieving the data is done using the Product, find(id) method, a class method in Active Record that 
retrieves a record with an id matching the passed id argument. In the statement above, this id argument 
is taken from the params hash passed to the controller via routing. 

To pass the data to the controller, we store the result of the find method to an instance variable of the 
controller. This instance variable will be passed by the controller to the view in the next part of the process. 


Ruby Corner - Class Methods 

Class methods (aka static methods to Java people) are methods that can be called even without an 
instance of the class. Product, find above is a class method. 

Class methods can be declared by adding “self. ” before the method name. For example, the change 
method in our migrations are declared as class methods that are eventually called by Rails. 

class SomeMigration < ActiveRecord :: Migration 
def self. change 
end 
end 


Ruby Corner - Instance Variables 

Instance variables are variables with an @ symbol before the variable name. As expected from instance 
variables, their scope extends to the entire class. 

Instance variables are not publicly accessible. They can only be accessed through accessor and mutator 
(getter and setter) methods. We can make it look like the instance variables are publicly accessible by 
the use of operator overloading: 

class Square 

def side_length 
@side_length 

end 

def side_length=(new_length) 

@side_length = new_length 


37 https://github.com/bryanbibat/rasm40code/commit/997e318479018f81eda7d6d8df42af29ee457308 
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end 

end 

s = Square. new 

puts s . side_length # returns nil 

s . side_length = 10 

puts s . side_length # returns 10 


Rails Conventions 

You might have noticed that we didn’t define the id field anywhere in our scripts or in our migration: 

create_table : products do | t I 
t. string :name 
t . text : description 
t. decimal :cost 
t. integer : stock 

t . timestamps 

end 


This is because by default, Rails adds “id”, an auto-incrementing integer primary key field, to all 
tables. By defining this field, developers don’t need to worry about defining primary keys in their tables. 
Also, as we shall see later, this scheme makes table relationships easier to code. 

Another thing to note is that scripts that generate table migrations automatically add two timestamp 
fields, created_at and updated_at, through the t. timestamps declaration. As their names imply, 
created_at contains the timestamp when the record was created, while updated_at contains the 
timestamp when the record was last updated. 


Display Model data using View 

We only have 2 more steps in the Rails MVC diagram: 

1. The controller sends the data to the view. 

2. The view renders the web page based on the data and sends it to the user. 

Rails automatically handles the first step: when you pass control over to the view at the end of the action 
method, Rails gives the view a bunch of variables to work on: 

• special variables like the params hash are available in the view through accessor methods 

• all instance variables in the controller are created instance variable counterparts in the view i.e. 
when you put values in the §product instance variable in the controller, you can access it in the 
view as@product 
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Now that we know that we can access @product in the view, the contents of our view should be easy to 
code. Replace the contents of app/views/products/show. html .erb 38 to: 

<hl>Show Product</hl> 


<p> 

<strong>Name : </strong> 
<%= ©product . name %> 

</p> 


<p> 

<strong>Descr iption : </strong> 
<%= ©product . description %> 

</p> 


<p> 

<strong>Cost : </strong> 

<%= number_to_currency(@product . cost, {:unit => ' PhP ' } ) %> 

</P> 


<p> 

<strong>Stock : </strong> 
<%= ©product . stock %> 

</p> 


Opening http : //localhost : 3000/products/l will give us the following result: 




: - n 

1 

AlingnenaApp 

X 


c 1 O localhost:3000/products/1 ft \ 


Show Product 

Name: test product 1 
Description: test description 1 
Cost: PhPl.ll 
Stock: 10 


And with that, our “Show Product” page is now complete. 


Ruby Corner - ERb expressions <%= %> 

Our view uses Embedded Ruby (ERb) files to define the contents of the view. As the name suggests, 
these files are basic text files with some Ruby embedded in them to provide dynamic content. 

In our example above, we used <%= %> to insert values into our page. When processing ERb files. Rails 


38 https://github.com/bryanbibat/rasm40code/commit/b28eaf690f7149df0f6c5a0937b43fd6faf8bd3e 
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scans the files for <%= %> and replaces them with the value of the Ruby expressions inside them. For 
instance, you could add the following line to the view to print out the current date and time: 

The time now is <%= Time, now %> 

J2EE developers might be familiar with this construct: it’s the same thing used to insert dynamic values 
in JSP pages. It’s called an “expression” in the JSP world, so we’ll use that term here too. 


Ruby Corner - Helper Methods 

Rails provides some helper methods to use inside a view. For example, we used the number_to_currency 
method in our view above. 

The number_to_currency method is self-explanatory; it simply converts the number provided to 
currency. It also provides some options for changing the currency symbol, the separator symbol, the 
format of the currency, etc. 


Ruby Corner - Escaping HTML characters 

Rails automatically escapes F1TML characters in views. Try visiting http : //localhost : 3000/products/2 
and check the contents of the description field. 

Rails provides a way of outputting raw data via theraw helper method. Try reloading the same page 
after enclosing the data with a raw method call: 

<%= raw(@product . description) %> 

Escaping F1TML important in web pages: if we do not escape text, malicious users can insert HTML 
code into our pages and attack our users with Cross-Site Scripting (XSS) and Cross-Site Request Forgery 
(CSRF) attacks. A simple example would be to go back into our Debts program and create a debt with 
“<script>alert( 'hello world! ' )</script>” as a customer or item, then add raw calls in either the 
index or the show pages. 



AlingnenaApp 



^ © O localh 

The page at localhost 

Name: 

hello world! 


☆ A. 
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Every user who views the item now has a JavaScript code run in their browsers. At this point, hacking 
the user’s personal information should only take the hacker a few more lines of code. Therefore, one 
must always take care in using displaying raw output via the raw helper. 


Shortcut Corner 

Following our method shortening tips, we can shorten our expressions to: 
<P> 

<b>Cost : </b> 

<%= number_to_currency @product . cost, unit: 'PhP' %></p> 

</p> 
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Adding a List Page 

Let’s move on to our List Products page. The approach is similar to the Show Product page, namely, we 
retrieve the records then render them in the view. 


Preparing the New Files 

We don’t need to create or modify anything for the view so let’s proceed with the controller. 

Rails Conventions 

For screens that list all products, the conventions are as follows: 

• the controller action should be namedindex 

• the URL should be / [controller] e.g. /products. Note the convention for controllers to be in 
plural form. 


There’s no script for updating the controller so we have to do the changes by hand. First, let’s apply the 
first convention above to the controller and view. Insert a new action index 39 to the controller (the order 
of the actions do not matter): 

class ProductsController < Appl icationControl ler 
def index 
end 

def show 

@product = Product . find(params [: id] ) 

end 

end 


Let’s also create a dummy view for the action, app/views/products/index . html .erb: 


<hl>Listing Products</hl > 

<table> 

<thead> 

<tr> 

<th>Name</th> 
<th>Descr iption</th> 
<th>Cost</th> 
<th>Stock</th> 

</tr> 

</thead> 

</table> 


39 https://github.com/bryanbibat/rasm40code/commit/0f9f98bfb76535a8ec07c08elf8abblc90f63755#diff-0 
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For the 2nd convention, we add a new route in con f i g/routes . r b 40 for routing the request to the controller 
action: 

AlingnenaApp Application routes draw do 
resources : debts 

get 'products' => ' products#index ' 

get ' products/ : id ' => ' products#show ' 

end 

You can now verify the routing by going to http : //localhost : 3000/products . 


iiioB- IM 

AlingnenaApp 


^ CO localhost:3000/products 

☆ * 

Listing Products 

Name Description Cost Stock 



Retrieving All Records 

In “show product”, we used the Active Record method f ind( ) to find a single record. For “list products”, 
we shall use al 1 ( ) . Add the following line to the index action 41 : 

def index 

©products = Product all 
end 

Using the a 1 1 ( ) class method instructs Active Record to retrieve all of records of the model. This variation 
of the method returns an array of objects instead of a single object. 


Ruby Corner - Arrays 

Arrays in Ruby are similar to arrays in C-based languages. They’re zero-indexed (i.e. the first element 
is indexed at 0) and access and modification is done using square braces ([ ] ): 

puts array [3] # outputs the contents of the 4th element of the array 

array [1] =10 # sets the 2nd element of the array to 10 

Arrays can also be initialized using square braces: 


4o https://github.com/bryanbibat/rasm40code/commit/0f9f98bfb76535a8ec07c08elf8abblc90f63755#diff-l 

41 https://github.com/bryanbibat/rasm40code/commit/ab39d8b4a2ddllaec677e640fa6f622068e0204d 
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my_array = [ "one" , "two" , "three" , " four" , "five" , "six" ] 

You can append new items into an array by using the < < operator. 
another_array = [ 10 ] 

another_array <<20 # the array now contains [10, 20 ] 

Like in hashes, you can put any combination of data types inside arrays: 

# array contains a number, string, symbol and an array 
mixed_array = [ 10, "twenty", : thirty, [40, 50 ] ] 

Ruby includes some built in functions for arrays. Here are some examples: 

puts an_array . size * outputs the size of the array 

an_array . delete_at(2) # deletes the 3rd element of the array 

Please refer to the API docs for other Array methods. 


Displaying the Records 

All we need to do now is to display the ©products array in the view. This part is slightly complicated so 
it’s OK to take a peek at how our Debts program handles it. 

<tbody> 

<% ©debts. each do I debt I %> 

<tr> 

<td> <%= debt . name %></td> 

<td><^= debt item ^></td> 

<td><^= debt. amount X></td> 

<td> <%= debt. remarks Z></td> 

</tr> 

end Z> 

</tbody> 

There are three new concepts in this code snippet alone. Let’s discuss two of them before we proceed with 
adding the actual code our view. 


Ruby Corner - iteration 

Ruby has for and while looping constructs but Ruby programmers rarely use them. 

Why? 

Because Ruby provides many ways of iterating through numbers and lists thanks to its functional 
programming influences. For example, a simple repetition task can be written as: 
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# print "hello world!" 10 times 

10. times do 

puts "hello world!" 

end 

Iterating through a list of numbers can be written using: 

# print numbers 1 to 10 

l.upto(10) do | number | 
puts number 

end 

# print numbers 10 down to 1 

10.downto(l) do I number I 
puts number 
end 

When you call upto( ) or downto( ), the method passes the current number to the variable enclosed in 
the pipe symbols ( I ) every iteration. The iteration method for arrays is similar: 

# print the contents of the array 

an_array . each do I item I 
puts item 
end 

Please refer to the API docs for other iteration related methods. You can tell if a method is an iteration 
related method if the final parameter for it is a block. (As we shall see later, blocks can either be enclosed 
in curly braces or a do -end block.) For arrays, you can look at both the API forArray as well as the API 
for its included class Enumerable. 

# print the contents of the array using Enumberable # each_with_index 
an_array . each_with_index do litem, indexl 

puts "The element at index *{index} is #{item}" 

end 

# adds 10 to each element in the array using Array#col lect ! 
an_array . col lect ! do I item I 

item +10 

end 


Ruby Corner - Scriptlets <% %> 

We’ve already discussed how expressions (<%= %> ) insert values into our ERb views. To insert actual code 
inside the ERb we can use the <% %> construct (note the lack of =). Here’s a simple example, rendering 
the contents of a variable initialized within an ERb: 

<% temp_var iable = 20 * 1024 %> 

<%= temp_var iable %> 


Code blocks are possible between these embedded ruby scripts. These blocks are rendered for every 
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iteration. For example, this code renders the contents of an array in an unordered HTML list: 

<ul> 

<% an_array . each do I item I %> 

<li><%= item %></li> 

<% end %> 

</ul> 

In J2EE / JSP terms, this construct is called a “scriptlet”. Like the JSP expressions, this ERb construct shares 
the same symbols as the JSP scriptlet. Because of this, we also call them “scriptlets” in this manual. 


Now that we are familiar with iteration and scriptlets, we can now code the rest of the app/v i ews/products/ index, htm 1 . er 
fde: 


<hl>Listing Products</hl > 

<table> 

<thead> 

<tr> 

<th>Name</th> 

<th>Descr iption</th> 

<th>Cost</th> 

<th>Stock</th> 

</tr> 

</thead> 

<tbody> 

<% @products . each do I product I %> 

<tr> 

<td> <%= product name 

<td><^= product description %></td> 

<td><^= number_to_currency (product . cost, :unit => "PhP" )%> </td> 

<td> <%= product . stock %></td> 

</tr> 

<£ end %> 

</tbody> 

</table> 

Once coded, we can now go to http : // loca 1 host : 3000/products to view the “list products” page: 


42 https://github.com/bryanbibat/rasm40code/commit/35df474aelbc709baf2dc2fff351b04c23885135 
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aHitU. mmm 

AlingnenaApp \<Q 

«- * c | 

O localhost: 3000/products 

☆ 

1 * 

Listing Products 



Name 

Description Cost Stock 




test product 1 test description 1 PhPl.ll 10 

test product 2 <b>test description 2</b> PhP2.22 20 


Since we’re done with the “list products” page, we now have time to discuss the third concept introduced 
in the above code: Ruby Blocks and Procs. 

Ruby Corner - Blocks and Procs 

Blocks and Procs are the cornerstones of functional programming in Ruby. The way they are used in this 
programming language is so complex and elegant that explaining them in detail in this manual would 
be a wasted effort. Instead, we would refer you to this wonderful article “for your reading pleasure. 

Here’s a very short explanation on what happens in @products . each: 

Blocks are like methods, but they still don’t have any bound data yet. They are declared using either 
do | varl , var2, ... I 
end 
or 

{ | varl , var2, ... I ... } 

When a block is passed to a method, the method would bind the values to the block and execute its 
statements. In the case of the each method, that method binds a new value into the block (e.g. the 
product variable) every iteration then runs the block. This is how the looping behavior works. 

Tittp://eli. thegreenplace.net/2006/04/18/understanding- ruby- blocks- procs- and- methods/ 


Linking the List Page with the Show Page 

Before we proceed with deleting records, let’s add links between the index and show pages together first. It 
can be annoying to manually type http : //localhost : 3000/products and http : //localhost : 3000/products/l 
just to go between these two pages. 

For this, we can use the 1 ink_to helper method. This method returns a link based on the arguments you 
pass it. The syntax is as follows: 


1 ink_to(name, options = {}, html_options_hash nil) 
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The name argument is the text used in the link. The options argument can be three different things: 

• a string - this will be the URL used by the link. As this is brittle for internal use (paths can be easily 
changed in the routes . rb), this is only used for external links. 

• a hash - the link will be based on both the hash and the routes . rb. 

• a non-hash, non-string object - Rails will create a URL based on this object, usually an Active 
Record. This will be discussed after we finish the entire Product program. 

Finally, the html_options_hash is simply a hash of HTML attributes you wish to assign to the link. For 
example, this link has the CSS class and the id set to “external-link” and “google-search”, respectively: 

<%= link_to("Go to Google", "http://www.google.com", 

{ :class => "hello world!", : id => "google-search"}) %> 

The resulting link is: 

<a href=" http : //www . google . com" class="hello world!" id="google-search" >Go to Google</a> 

If the text is too long, you can use the block form of 1 ink_to: 

1 ink_to(options = {}, html_options_hash = nil) do 
* name 

end 

To use it, just put the text inside the block: 

<%= 1 ink_to( "http : //www . google . com" ) do Z> 

<strong>This link goes to Google</strong> 

<% end %> 


Now that we know how to use 1 ink_to, let’s link the show and index pages. Insert the following line to 
index. html.erb 43 : 


<% @products . each do I product I %> 

<tr> 

<t&> <%= product. name ^></td> 

<t&> <%= product . description ^></td> 

<td> <%= number_to_currency(product . cost, :unit => "PhP" )%> </td> 

<td> <%= product . stock X></td> 

<td> <%= link_to( 'Show' , { :action => 'show', :id => product. id }) ^></td> 

</tr> 

<% end %> 


And add the following line to the end of show . html . erb 44 : 

43 https://github.com/bryanbibat/rasm40code/commit/faddfe67b302a6db9fa0c5886e08c62b7ececf8a#diff-0 

44 https://github.com/bryanbibat/rasm40code/commit/faddfe67b302a6db9fa0c5886e08c62b7ececf8a#diff-l 
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<%= 1 ink_to( ' Back to List of Products’, { : action => ’index’ }) %> 


Shortcut Corner 

1 ink_to is just another method so we could use the usual shortcuts for Ruby methods like removing the 
parenthesis and the curly braces: 

<td> <%= link_to ’Show’, : action => ’show’, : id => product. id %></td> 

The tricky part here is that the method accepts 2 different hashes so you might think the shortcut won’t 
work. However, remember that Ruby parses the last series of hash key-value pairs as a single hash: if 
we want to pass 2 hashes, we just need to enclose the first hash in curly braces. For example, if we want 
to set the class of the link to the show product screen, we can use: 

<td> 

<%= link_to ’Show', { :action => ’show’, : id => product. id }, :class => ’link’ %> 

</td> 


Named Routes 

There are a couple of problems with using an options hash in 1 ink_to. The most obvious problem is that 
it’s too long. Even if the : control ler and : action options can be derived from the current page, it’s still 
too long for practical usage. 

Another problem is that it’s brittle. Suppose we have a link scattered around our system, say an approve 
account link. Initially our link goes to the approve_account action in the users controller so our links 
were generated using: 

<%= link_to 'Approve Account’, : control ler => ’users’, : action => ’ approve_account ’ %> 

Later, we changed the page that handles the account approval to theapprove action of the accounts 
controller. We would have to manually search all instances of the approve account link and modify it 
accordingly. 

<%= link_to 'Approve Account’, :controller => ’account’, :action => ’approve' %> 

To remedy these two problems, Rails provides a way for us to name routes in theroutes.rb file. 

Here’s how you modify our routes for index and show to become named routes 45 : 


45 https://github.com/bryanbibat/rasm40code/commit/32b24f96a02aa68acf02315f06729d3afd2a9ebS 
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AlingnenaApp : Application routes draw do 
resources : debts 

— get — ' products ' — => — ' products*indcx ' 

— get — ' products/ : id ' — =-> — ' products*show ' 

get 'products' => ' products#index ' , :as => 'products' 
get ' products/ : id ' => ' products#show ' , :as => 'product' 

end 

By adding an : as option, we tell Rails to provide two new helper functions based on the route: 

• xxxx_path - returns the relative path of the matched route. For example, calling products _path 
will return /products 

• xxxx_ur 1 - returns the complete URL of the matched route. For example, calling products_ur 1 will 
return http : //local host : 3000/products 

The path and URL are interchangeable in almost all cases. For this manual, we shall use the xxxx_- 
path methods due to it being used in generator scripts. Flere’s the named route version of the link in 
show.html. erb 46 : 

<%= link_to 'Back to List of Products’, products_path %> 

When the path in the route contains placeholder symbols, both methods accept arguments to fill up these 
placeholders. For example, if we want to generate the URL to a certain product, we can use 47 : 


<td> <%= product . stock %></td> 

<td>':/u~ link_to — ' Show ' , — action : — 1 show ' , — LeL — product, id U</td> 

<td> <%= link_to 'Show', product_path( product id) £></td> 

</tr > 

end 


Shortcut Corner 

You can directly provide Active Record objects when providing arguments for the named route helpers. 
The helpers will just retrieve the id of the record for you. For example: 

<td> link_to — ' Show ' , — product_path ( product . id) ,°n</td> 

<td > <%= link_to 'Show', product_path(product) £></td> 


Later, we shall see how we can directly use Active Record objects as arguments for link_to. This 
approach uses conventions in named routes. At this point, we can actually use our Product object 
because our named route matches the convention for routing. 


46 https://github.com/bryanbibat/rasm40code/commit/887cl9ce44242ea57a969e949716dfl875cl3015#diff-l 

47 https://github.com/bryanbibat/rasm40code/commit/887cl9ce44242ea57a969e949716dfl875cl3015#diff-0 
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<td>'4.'~ link_to — 1 Show 1 , — product_path( product) %></td> 

<td > <%= link_to ’Show', product ^></td> 


Rails Applications Without Scaffold (part 2: 
Delete and Search) 

Deleting a Record 

Our next task is deleting a record. Deleting is similar to showing a record, the only differences being the 
HTTP verb involved and that instead of rendering the specified record, we destroy it. 

That said, this task has three steps that we need to code: 

1. Provide a way to call the controller action for deleting a product 

2. Delete the product record in the controller action 

3. Display the “list products” page after deleting the product 


Rails Conventions 

For screens that deletes records, the conventions are as follows: 

• the controller action should be named destroy 

• as mentioned in the REST discussion, the URL for delete is the same as the URL for show. Instead 
of using the default GET verb, we use the DELETE verb for deletion i.e. DELETE /products/: id 


Creating a DELETE link 

We already know how to create a GET link. In this part, we shall discuss how to create a DELETE link. 
First off, let’s create a new route 48 for delete based on the conventions: 

AlingnenaApp : Application routes draw do 
resources : debts 

get 'products' => ' products#index ' , :as => 'products' 
get ' products/ : id ' => ' products#show ' , :as => 'product' 

delete 1 products/ : id 1 => 1 products#destroy 1 

end 

Here we see how Rails can differentiate between the HTTP methods. The destroy action will only be used 
when the HTTP method is DELETE. 

With the route set, we can now modify our controller to add our new destroy action 49 . 

48 https://github.com/bryanbibat/rasm40code/commit/57e0a8b37bf7304d64cbeb4fbea5ea88a72a064e#diff-2 

49 https://github.com/bryanbibat/rasm40code/commit/57e0a8b37bf7304d64cbeb4fbea5ea88a72a064e#diff-0 


Rails Applications Without Scaffold (part 2: Delete and Search) 


54 


def destroy 

# destroy the specified record 

redirect_to products_path 

end 

The redirect_to method can be used to replace a view. Instead of rendering a view, it tells the user’s 
browser to redirect to another page, resulting in a fresh new request to the target page. In this case, we 
redirect the user to the "list products” page after deleting the record. 

The parameters for redirect_to is the same as the 2nd parameter for link_to (they use the same helper 
method, ur 1 _f or ) so you can use string for direct URLs, hash for route based URLs, or objects for shortcuts. 

Now that we’ve finished setting up the route and the controller, it’s time to make the actual link. Add the 
following to app/views/products/show . html . erb 50 : 


</p> 

<%= link_to( ' Delete this record', §product, 

{ :data => { :confirm => 'Are you sure?'}, :method => :delete }) %> <br> 

<%= link_to 'Back to List of Products', products_path %> 

As you can see, this is practically the same as the “Show” link; we only added some new html_options to 

change the behavior of the link. 

link_to has 3 special html_options: 

• :data - This option can be used to add custom data attributes. For example, with : confirm => 
"question?" you can set a confirmation question which will be prompted to the user on click of 
the link. The link is processed normally if the user accepts. 

• : method - this accepts an HTTP verb symbol, either : post, : put, or : delete. With this set, clicking 
the link will call a JavaScript function which will submit a request to the specified URL with the 
specified method. If JavaScript is disabled, the link will fall back to GET. 

• : popup - This will force the link to open in a popup window. By passing true, a default browser 
window will be opened with the URL. You can also specify an array of options to pass to JavaScript’s 
window. open method. 

By using : data => { : confirm } and : method, we create a link that both prompts the user if he wants 

to continue and sends a request using the DELETE method. 

Trying this out results in: 


5 °https://github.com/bryanbibat/rasm40code/commit/57e0a8b37bf7304d64cbeb4fbea5ea88a72a064e#diff-l 
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Q AlingnenaApp 


c © localhost:3000/products/l 


Show Prod 

Name: test product 1 
Description: test desc 
Cost: PhPl.ll 
Stock: 10 


Delete this record 


Back to List of Products 


The page at localhost 



☆ A 


Clicking OK will redirect us to the “list products” screen, confirming that the link and route works. 

Deleting the Product 

Now it’s time to add the missing lines in our destroy method 51 : 
def destroy 

©product = Product . find(params [: id] ) 

@product destroy 

redirect_to products_path 

end 


The first line retrieves the record in from the database. We’ve already seen this in our show method. 
The second line deletes the record using the Active Record destroy method. Simple, huh? 

Trying this out, we see: 



c 


O localhost: 3000/products 


☆ ^ 


Listing Products 


Name Description Cost Stock 

test product 2 <b>test description 2</b> PhP2.22 20 Show 


51 https://github.com/bryanbibat/rasm40code/commit/180b6712ecf30a9d24d4f9b43ac03bd5cfcl41bb 
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Re-running a Migration 

We’re still going to add another feature to our destroy action, but before that, we’re going to have to deal 
with a certain problem first: running out of test data. We only have two test records so we’re bound to 
end up with an empty database when we continuously test our destroy action. 

Thankfully, there’s a command for re-running a migration: 

$ rake db : migrate : redo 

This command rolls back the previous migration and runs it again. You can also specify the number of 
migrations to roll back and re-run by using the STEP environment variable: 

$ rake db : migrate : redo STEP=3 

Note that re-running a migration will reverse the migration first by converting calls in the self, change 
method of the migration to their exact opposite (e.g. from create_table to drop_table). This may or may 
not damage your data, but it’s something to keep in mind. 

Displaying a Message using Flash 

The missing feature we’re talking about earlier is the lack of confirmation messages. Right now, our 
program simply deletes the record and redirects the user without telling her if the operation was successful 
or not. 

We use instance variables to pass data from the controller to the view. However, data in the instance 
variables are only present in the current request. A new request is generated when we useredirect_to so 
all of our instance variables are cleared. So for messages to be displayed after a redirect, we have to use 
another controller specific container: the flash hash. 

Like the params hash, the flash hash is available for use in both the controller and the view. What’s 
different is that items put inside the flash hash last until the next request. 

Here’s how to modify our destroy action to include a flash message 52 : 
def destroy 

§product = Product . find(params [: id] ) 

§product . destroy 

f lash [: notice] = "Product was successfully deleted." 

redirect_to products_path 

end 

Then we add an additional line at the top of app/views/products/index. html .erb 53 to display the 
message (the scaffold stylesheet already includes ^notice): 


52 https://github.com/bryanbibat/rasm40code/commit/4d3cabaed78cc9e243d3fdd4fl81ebbbd982ee40#diff-0 

53 https://github.com/bryanbibat/rasm40code/commit/4d3cabaed78cc9e243d3fdd4fl81ebbbd982ee40#diff-l 
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<p id="notice "> <%= f lash [: notice] %></p> 


<hl>Listing Products</hl > 


Trying the destroy link now results in: 


II 

irzirB - ! 

Li 




© localhost:3000/products & 



Product was successfully deleted. 


Listing Products 

Name Description Cost Stock 

test product 2 <b>test description 2</b> PhP2.22 20 Show 


Note that items in the flash hash last until the next request. If you don’t redirect, a message will be 
present in both the current request and the next request. You can use flash . now instead of flash to set 
messages that are only available in the current request. 

By the way, the most common types of flash messages are : notice (information messages, often in green) 
and : alert (error messages, often in red). We shall see these two again later. 

Adding a Search Screen 

Just as deleting records is similar to showing records, filtering records is also similar to listing records. 
Here’s the process for searching / filtering product records: 

1. Submit a query to a search action 

2. The search action retrieves records based on the query 

3. Render the retrieved records using the view 

In this part, we introduce two new concepts: generating HTML forms in the view, and using an Active 
Record dynamic finder for searching records. These two concepts deal with step 1 and 2, respectively, 
while we already know how to do the third step. 

Rails Conventions 

There is no built-in convention for search screens in Rails. However, since we are performing an 
operation to the entire table (searching), the request should be done in the/products path e.g. “GET 
http: //localhost: 3000/products/search ”. The controller action as well as the view file name should 
follow the URL. 


As for the parameters, since this is just a GET operation, query strings can be used as they are normally 
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used e.g. http : //localhost : 3000/search?name=test . 


Preparation 

The choice for the action name is arbitrary so let’s just stick to “search”. With that in mind, let’s modify 
our controller and view accordingly. Let’s start off with a new route 54 : 

AlingnenaApp : Application routes draw do 
resources : debts 

get 'products' => ' products#index ' , :as => 'products' 

get ' products/search 1 => ' products#search 1 , :as => ' search_products ' 

get ' products/ : id ' => ' products#show ' , :as => 'product' 
delte ' products/ : id ' => ' products#destroy ' 

end 

We added a named route “search_products” pointing to our new action so that we could simply use 
search_products_path in our form later. 

Let’s add the search action to app/controllers/products_controller .rb 55 : 


def search 

@products = Product. all 

end 

We’re not doing any filtering yet; we’re just copying the approach in the index action. We’ll continue with 
the index-cloning with app/views/products/search . html . erb 56 : 


<hl>Listing Products</hl > 

<table> 

<thead> 

<tr> 

<th>Name</th> 

<th>Descr iption</th> 

<th>Cost</th> 

<th>Stock</th> 

</tr> 

</thead> 

<tbody> 

<% ©products . each do | product I %> 

<tr> 

54 https://github.com/bryanbibat/rasm40code/commit/4eec83249f7b52076040d59993a082165999b7f5#diff-2 

55 https://github.com/bryanbibat/rasm40code/commit/4eec83249f7b52076040d59993a082165999b7f5#diff-0 

56 https://github.com/bryanbibat/rasm40code/commit/4eec83249f7b52076040d59993a082165999b7f5#diff-l 
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<td><X= product. name %></td> 

<td> <%= product description %></td> 

<td><^= number_to_currency product . cost, unit: 
<td><^= product . stock ^></td> 

<td><^= link_to 'Show', product ^></td> 

</tr> 
end £> 

</tbody> 

</table> 


' PhP ' %> </td> 


Yes, it’s basically a copy of app/views/products/index.html .erb. 

Adding the Search Form to List Products 

As web developers, we already know how to tinker with the URL to pass query strings to the server. Our 

users obviously don’t know how to do that manually so we have to provide a search form for them to use. 

Insert the following lines to app/views/products/index.html .erb 57 : 

<%= form_tag(search_products_path, {:method => :get} ) do %> 

<%= label_tag( "name" , "Search by product name:") %> 

<%= text_f ield_tag( "name" ) %> 

<%= submit_tag( "Search" ) %> 

<% end Z> 


If you view the source of the updated form, you will realize that every helper we used corresponds to an 
HTML form element. 


$ > Console 

0 inspector 

© Debugger 

Gf Style Editor 

0 Profiler 

~r Network 

C5 html 

body form 

div 





<!D0CTYPE html> 

y <headx/head> 

A <body> 

► <hlx/hl> 

<p id="notice"x/p> 

method="get M action="/products/search" accept-charset="UTF-8"> 

A <div style="ma rgin : 0 ; padding : 0 ; display : inline H > 

<input type="hidden" value=V" name= M utf8 M x/input> 

</div> 

^<label for="name"> 

Search by product name: 

</label> 

<input id="name" type= M text" name="name"x/input> 

<input type="submit" value= H Search" name="coirnnit M x/input> 

</form> 

y <tablex/table> 

</body> 

</html> 


The f orm_tag helper generates a form element, enclosing everything inside the block inside the form. Its 
syntax is (note that the tag must be in an expression, not a scriptlet): 


57 https://github.com/bryanbibat/rasm40code/commit/16c944al70affe33871af71a703d9a9b2e5671al 
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<%= form_tag(url_for_options = {}, options = {}, *parameters_for_ur 1 ) do %> 


<% end %> 


The ur l_for_options are the same as the options used in 1 ink_to and redirect_to (the string, hash, or 
object parameter in case you forgot). Like 1 ink_to, the second hash allows you to set HTML attributes for 
the form along with two additional options: you can set : multipart to true if you want to set the enctype 
to “multipart/ form-data” (useful for submitting files), and you can set the : method to either :get, :put, 

: post, or : delete (: post is used by default). The parameters_for_url is simply a hash. 

Here’s a quick rundown on the other form helpers we used in the search form: 

• label_tag - creates a label. It has 3 parameters: 

- first parameter sets the for attribute 

- second parameter sets the text inside the label. Uses the value of the first argument if not 
specified. 

- third parameter is a hash for setting HTML attributes 

• text_f ield_tag - creates a standard text field. Also has 3 parameters 

- first parameter sets the name attribute 

- second parameter sets the value of the field 

- third parameter is a hash for setting HTML attributes. You can also set additional options: 
you can set disabled to true to disable the field, you can also set the :size to set the number of 
visible characters that will fit in the input, and you can also set the :maxlength which is the 
maximum number of characters that the browser will allow the user to enter. 

• submit_tag - creates an HTML submit button. It only has two parameters: the first sets the text 
inside the button (default is “Save changes”) and the second is an options hash for setting HTML 
attributes. Like with link_to, form_tag and text_field tag, this parameter has some special 
options: 

- : confirm - behaves the same way as thexonfirm in link_to 

- : disabled - disables the button if set to true 

- : disabled_with - if this is set and the user clicks the button, the button will be disabled and 
the provided text (e.g. “Please wait...”) will replace the button’s original text while the form is 
being submitted. Useful for preventing the user from clicking the button twice on submit. 

We only used one field in our form, the name field. Our plan is for this search module to return all records 
with a name that matches our submitted name. But enough talk, let’s see our newly coded form in action: 


II 

I AlingriHfidApp: 

I «- c 

© localhost:3000/products/search?utf8=^&name=test+product+1&c ^ 

M 



Listing Products 


Name Description Cost Stock 

test product 1 test description 1 PhPl.ll 10 Show 

test product 2 <b>test description 2</b> PhP2.22 20 Show 
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As you can see, the get method puts the query string in the URL. We could verify that the parameters 
were passed by looking at the web server logs. 


Started GET "/products/sea rch?utf8=%E2%9C%93&name=test+product+l&commit=Search" 
for 127.0.0.1 at ■ ■ +0800 

Processing by ProductsController#search as HTML 

Parameters: {"utf8"=>'V" , "name"=>"test product 1", "commit"=>"Search"} 
Product Load (0.6ms) SELECT "products”.* FROM "products" 

Rendered products/search. html.erb within layouts/application (19.8ms) 

Completed 200 OK in 37ms (Views: 26.1ms | ActiveRecord: 0.6ms) 


With this we know that we could access the search parameter “name” through the params hash entry 
params [ : name] . 

Shortcut Corner 

We can shorten the entire form the same way we shortened our other model forms: 

<%= form_tag search_products_path, method: :get do %> 

<%= label_tag "name", "Search by product name:" %> 

<%= text_f ield_tag "name" %> 

<%= submit_tag" Search" %> 

<% end %> 


Filtering Results 

So now we have the search parameter available in our controller. Let’s now add the code which will filter 
the results accordingly. Replace the line in the search action with 58 : 

def search 

©products = Product . f ind_all_by_name(params [: name] ) 
end 

Here we used a dynamic finder. In addition to providing accessors for each field in the database, Active 
Record also provides class methods for retrieving filtered for each field. These methods are in the form of: 

• . f ind_by_xxxx( ) - returns a record whose field xxxx matches the provided argument. Like . find(), 
it throws an error if no record is found. (When you think about it, find equivalent to f ind_by_id) 

• . f ind_al l_by_xxxx( ) - returns an array of records whose field xxxx matches the provided 
argument. 

Unfortunately, these methods are already deprecated and will be removed in Rails 4.1. Later we shall 
discuss a more flexible method for filtering, the where method. 

The search function should work properly at this point. Try using the search form at http : // loca 1 host : 3000/products 
to see if it works. 


58 https://github.com/bryanbibat/rasm40code/commit/02365d2el9bla35a820d75fe6bb9c6b7c2248d93#diff-0 
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Finishing Touches to the View 

Let’s make some minor changes to our search results screen to make it more functional 59 . 


<hl>Listing Products</hl > 

<p>Displaying Products with name " <%= params [ : name] %>"< /P> 


<table> 

<thead> 

<tr> 

<th>Name</th> 

<th>Descr iption</th> 

<th>Cost</th> 

<th>Stock</th> 

</tr> 

</thead> 

<tbody> 

<% ©products . each do | product I %> 

<tr> 

<td><%= product. name %></td> 

<td> <%= product description %></td> 

<td> <%= number_to_currency product. cost, unit: 'PhP' %></td> 
<td> <%= product . stock ^></td> 

<td><%= link_to 'Show', product Z></td> 

</tr> 

<Z end 
</tbody> 

</table> 


<p ><%= link_to "Back to original list", products_path %></p> 


The first change displays the current search criteria, while the next change links back to the original list, 
basically resetting the filter. 




- n 


Wm AlingnenaApp 

BBjjj^k + 


) localhost:3000/products/search?utf8=^&name=test+product+1&c ^ ^ 


Listing Products 

Displaying Products with name "test product 1" 

Name Description Cost Stock 

test product 1 test description 1 PhPl.ll 10 Show 


5, https://github.com/bryanbibat/rasm40code/commit/02365d2el9bla35a820d75fe6bb9c6b7c2248d93#diff-l 
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Insert and Update) 

Creating a Record 

So far we’ve encountered tasks that require one controller action and one view as well as a task that 
required only one action with no views (delete). For next two tasks, creating and updating a record, we 
will need two actions and one view: 

• one action to prepare the form 

• one view to render the form to the user 

• one action to process the submitted form. This action will simply redirect in case of success or 
re-render the view in case of an error. 


The flow for creating records is slightly more complicated than the previous functions so let’s just discuss 
the flow as we go along. 


Rails Conventions 

Here are the conventions for screens that create records: 

• the controller action that prepares the empty form should be named new. The view displaying 
the empty form also follows (new . html . erb) 

• the URL to the empty form should be in the form / [plural model ] /new, so in the Product case, 
this should be /products/new. This still follows REST; we are performing an action that affects 
the entire table. 

• the controller action that processes the submitted form should be named create. 

• the URL to the form processing action should not be / [plural model ] /create, but POST 
/[plural model] i.e. POST /products. The base path is fine because the method tells the server 
that we are posting a new item to products. 


Preparing the New Files 

First step is to insert new actions into our controller. The pseudocode 60 below explains the basic flow for 
this function: 


6 °https://github.com/bryanbibat/rasm40code/commit/857fbdd9540 16 12 1 1 Ic2a39cdl8b8cbdacb029ed#diff- 0 
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def new 

# create a dummy Product 

end 

def create 

# create a Product based on submitted form 

# save Product 

# if save is successful 

# show new Product 

# else 

# go back to current page and display error 

end 


Let’s also create a dummy app/views/products/new. html .erb 61 so we could test the routing before we 
add the processing logic. 

<hl>New Product</hl> 

<p>form goes here</p> 

Here are the new entries for our routes . rb 62 : 


A1 ingnenaApp : : Appl ication routes draw do 
resources : debts 

get 'products' => ' products#index ' , :as => 'products' 

post 'products' => ' products*create ' 

get 'products/new' => ' products*new ' , :as => ' new_product ' 

get 'products/search' => ' products#search ' , :as => ' search_products ' 
get ' products/ : id ' => ' products#show ' , :as => 'product' 
delete ' products/ : id ' => ' products#delete ' 

end 


Try out the new screen by going to http : //localhost : 3000/products/new: 




finTTol 

— 

AlingnenaApp 



C © localhost:3000/products/new *£? \ 


New Product 

form goes here 


61 https://github.com/bryanbibat/rasm40code/commit/e2ef53edec84a415fdl9ef664d95b3234899fb69 
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Making the Create Form 

Here’s the rest of new . html . erb 63 : 

<hl>New Product</hl> 

<%= form_for @product do |f| %> 

<div class=" field" > 

<%= f. label :name %><br> 

<%= f.text_field : name %> 

</div> 

<div class=" field" > 

<%= f. label :description %><br> 
<%= f . text_area : description %> 
</div> 

<div class=" field" > 

<%= f. label :cost %><br> 

<%- f.text_field : cost %> 

</div> 

<div class=" field" > 

<%= f label : stock %><br> 

<%= f.text_field : stock %> 
</div> 

<div class="actions" > 

<%= f. submit 'Create' %> 

</div> 

<Z end %> 


<%= link_to 'Back', products_path %> 

We’re using a different form helper here; before, we used form_tag in our search screen, while here we 
used form_for. The former is called a non-model form because it doesn’t use a model. On the other hand, 
form_for is a model form - it takes a model and uses it to populate the fields inside the form. 

The syntax for form_for is as follows: 

form_for(record_or_name_or_array , options = {}) do [ f I 

end 

The record_or_name_or_array parameter determines the model/s used in the form. As the name implies, 
it accepts a single or an array of Active Record objects and also accepts a name, a symbol or a string that 
refers to the instance variable where the Active Record is stored. The options argument can accept two 
options: 

• : url - the URL where the form is supposed to be submitted to. Normally, the URL is derived from 
the model in the first argument but we can override that by using this option. The expected value 
for this option is the same expected values for 1 ink_to and redirect_to, namely, either a string, a 
hash, or an object (i.e. this option also uses url_for). 


63 https://github.com/bryanbibat/rasm40code/commit/fbf79ae3b611980449ff300fb86c7cb6b4cabd0e#diff-l 
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• : html - you can pass a hash of HTML attributes to this option 

Inside the block are model form helper counterparts to the non-model form helpers we used in search. 

There are some noticeable differences, though: 

• They use symbols for their first parameter. This signifies that they refer to a specific field in the 
model provided in the form_for call. 

• They are prefixed by an “f . ”. When the block is called by form_for, form_for passes an object that 
refers to the model of the form. When we prefix a form helper with the “f ”, we say that the field is 
a member of the form. We can do away with the f prefix, but doing that would require us to tell 
the form helpers what model they should refer to. e.g.: 


<%= text_field( : products, :name) %> 

You may notice that we haven’t initialized the @product instance variable yet. Let’s do just that in the new 
action 64 : 


def new 

©product = Product. new 
end 

Opening http : //local host : 3000/products/new will give us a blank form. 


64 https://github.com/bryanbibat/rasm40code/commit/fbf79ae3b611980449ff300fb86c7cb6b4cabd0e#diff-0 
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s 

— '“nl 


1 

1 AlingnenaApp 


| ^ CO localhost:3000/products/new *£? 



New Product 


Name 



Product, new is the constructor of the Product class. We can even define the fields at this point passing 
a hash of “field name - value” pairs. Try replacing Product. new with Product. new( :name => "dummy 
name" ) . You should see the name field in the form populated by “dummy name”. 


Saving the New Record 


When we click on submit, the contents of the form are submitted and Rails converts the form into a single 
hash parameter. 


Started POST "/products" for 127.0.0.1 at 2011-02-22 02:37:45 +0800 
Processing by ProductsController#create as HTML 

Parameters: {"utf8"=>"/" , "authenticity_token"=>"RDf30n5ghYVgvJI8/xDYUZA6sltQi 
HUKLtOEnjtdOEY=" , "product"=>{"name"=>''Cola" , "description"=>"fizzy drink” , "cos 
t"=>"25" , "stock"=>"100"}, "commit"=>"Create"} 

Completed in 29ms 


This hash is now part of the params hash and can be accessed directly like any hash entry. Here’s a visual 
representation of params: 
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key 

value 

: commit 

Create 

: authenticity_ token 


: product 

key 

value 


: name 

Cola 

description 

fizzy drink 

:cost 

25 

: stock 

100 


Here we can see that we could access the value “Cola” via params [ : product] [ : name] or the whole product 
hash via params [ : product] . 

Now the only thing left to do is code the logic that we wrote in pseudocode, namely, to create a record 
based on the submitted form, save that record, then redirect the user based on the results of the save. 

The first part can be done by using Product’s constructor 

def create 

@product = Product . new( params [: product] ) 

# save Product 

# if save is successful 

# show new Product 

# else 

# go back to current page and display error 

end 

Recall that the constructor accepts a hash and fills out the fields based on that hash. Passing params [ : product] 
(which is a hash) creates a new Product object based on the submitted form. 

The saving and redirection can be done via the following code 65 : 
def create 

§product = Product . new( params [: product] ) 

i f @product save 

f lash [: notice] = "Product has been successfully created." 
redirect_to @product 
else 

render : action => "new" 
end 
end 

Here we called save, an instance method that saves the record to the database. This method returns true 
if the record passes validation and false otherwise. 


65 https://github.com/bryanbibat/rasm40code/commit/79e2b4fbb7a316e34867cl29931f9d0d3fe021e4 
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On a successful save in our code, the user is redirected to the “show product” page of the newly created 
Product record. Try using the new product form now. 


' Q Action Controller: Excf x \ 

♦ ♦ o | Q localhost:3000/products E 



There seems to be an error in our code! 

Never fear, this ForbiddenAttributesError is Rails’s way of warning us to not trust user’s input when 
creating or updating our models - a clever user can modify the data they send over our application and 
could modify the fields that we didn’t specify in our forms. 

To avoid this, we must directly state 66 which parameters to accept in our controllers. This is the concept 

of strong parameters: 

def create 

©product = Product . new(params require! : product) 

permit( : name, description, :cost, :stock)) 

if ©product . save 

Now that we have fixed the error try resending the data by refreshing the page: 


66 https://github.com/bryanbibat/rasm40code/commit/4elbadlbb301ac5401dc53ad7724f44ae660e979#diff-0 
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— n 


| AiingnenaApp 

V 


^ C O localhost:3000/products/3 


Product has been successfully created. 

Show Product 

Name: Cola 

Description: fizzy drink 

Cost: PhP25.00 

Stock: 100 

Delete this record 
Back to List of Products 


☆ * 


To display the success notice in the show product page, add the following line from app/v i ews/products/ index, htm 1 . er b 
to show . html . erb 67 : 


<p id="notice " > <%= f lash [: notice] Z></p> 

If the save fails, it calls the render method to render the view of the new action. By rendering the view of 
the new action, the user is presented a form that contains the data that he submitted along with the error 
messages that comes along with it. This is the reason why we initialize the ©product variable in the new 
action instead of initializing it directly at new . html . erb. 

Unfortunately, we can’t see this in action because we haven’t set validation rules for Product yet. 

Ruby Corner - Decision Making 

The i f statement in Ruby looks like the following: 

if expression then 

end 

The then keyword is optional unless the whole statement is in a single line 
if expression then . . . end 

Adding else and else-if in the statement gives us the following: 

if expression [then] 
elsif expression [then] 
else 


67 https://github.com/bryanbibat/rasm40code/commit/4elbadlbb301ac5401dc53ad7724f44ae660e979#diff-l 
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end 

You can also use unless which evaluates the statement if the expression is false: 

unless expression [then] 

else 

end 

Both i f and unless can also be used as statement modifiers where the statement would be run if their 
conditions are met. For example: 

return true if x > max_value 
error_count += 1 unless form is_valid? 

Note that as we mentioned before, everything evaluates to true except for nil and false in Ruby. 


Shortcut Corner 

As mentioned before, : alert and : notice are so common that the Rails team decided to add convenient 
ways to set and retrieve these flash messages. 

In redirect_to, there’s the special options : alert and : notice which allows you to set flash [ : alert] 
and flash [ : notice] , respectively: 

redirect_to @product, : notice => "Product has been successfully created." 

There are also notice and alert helpers that serve a similar purpose: 

<p id~"notico" > f lash [: notice] %></p> 

<p id="notice "> <%= notice %></p> 

Remember that you can also use JSON-style hashes to further shorten your code: 
redirect_to @product, notice: "Product has been successfully created." 


Basic Validation 

Let’s add some basic validation to our Product model. Add the following line to app/model s/product . rb 68 : 


68 https://github.com/bryanbibat/rasm40code/commit/a404d8fef97bb862b4ae6aa9c949daba6daba8cd#diff-0 
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class Product < Acti veRecord : : Base 

validates( : name, : presence => true) 
validates( : description, :presence => true) 
end 

This method call to validates_presence_of tells Rails to check whether the specified fields are present 
when the object undergoes validation. In other words, it defines the mandatory fields for the model. 

We also add the following lines to new . html . erb 69 to display the error messages: 

<hl>New Product</hl> 

<%= form_for @product do |f| %> 

<% if @product errors any? %> 

<div id="error_explanation"> 

<h2 > <%= pluralize(§product errors count, "error") %> prohibited this product from 
being saved :</h2> 

<ul> 

<% §product . errors ful l_messages each do Imsgl %> 

<li> <%= msg ^></li> 

<% end %> 

</ul> 

</div> 

<% end %> 

<div class=" field" > 

<%= f label :name ^><br /> 


Try submitting a blank new product form now. 



M https://github.com/bryanbibat/rasm40code/commit/a404d8fef97bb862b4ae6aa9c949daba6daba8cd#diff-l 
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You are redirected to new . html . erb along with messages detailing the errors in your form. As you may 
have guessed, the error messages at the top are the work of the f . error_messages call. 

Before we end this part, add a link to the “new product” page in the “list products” page (i.e. i ndex . html . erb 70 ): 


</table> 

<p > <%= link_to "Create a new Product", new_product_path %>< /P> 

We’re done with creating new product records and we only have one more function to code. 

Shortcut Corner 

Since the validation is just a method call, we could also write it as: 

class Product < ActiveRecord : : Base 

validates :name, presence: true 
validates description, presence: true 
end 


Editing a Record 

Editing a record is not that different from creating a record. We still have two controller actions sharing 

one single view which contains the form; we just don’t create the record from scratch this time. 

Rails Conventions 

Here are the conventions for editing records: 

• the controller action that prepares the editing form should be named edit. The view displaying the 
empty form also follows (edit.html .erb) 

• the URL to the form should be in the form /[plural model] /[id] /edit, so in the Product case, 
this should be /products/: id/edit. This RESTful URL tells us that we are doing an action to a 
particular product resource. 

• the controller action that processes the submitted form should be named update. 

• the URL to the form processing action is similar to the one we used in showing and destroying a 
record: PATCH /products/: id or PUT /products/ : id. 


Routes and View 

Insert the following new entries in routes. rb 71 : 


7 °https://github.com/bryanbibat/rasm40code/commit/c2b7255ad92d98107652567badb508426ale8lb6 
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A1 ingnenaApp : : Appl ication routes draw do 
resources : debts 

get 'products' => ' products#index ' , :as => 'products' 
post 'products' => ' products#create ' 

get 'products/new' => ' products#new ' , :as => ' new_product ' 
get 'products/search' => ’ products#search ' , :as => ' search_products ' 
get ' products/ : id ' => ' products#show ' , :as => 'product' 
delete ' products/ : id ' => ' products^delete ' 

patch ' products/ : id ' => 1 products # update' 
put ' products/ : id 1 => ' products#update' 

get ' products/ : id/edit 1 => ' products*edit ' , :as => ' edit_product ' 
end 


Create the view file for edit, app/views/products/edit . html . erb 72 : 

<hl>Edit Product</hl> 

<%= form_for §product do |f| %> 

<% if @product . errors . any? %> 

<div id="error_explanation" > 

<h2 > <%- plural ize @product . errors . count, "error" %> prohibited this product from 
being saved :</h2> 

<ul> 

<% §product . errors . ful l_messages . each do I msg I %> 

<li><^= msg %></li> 

<% end 

</ul> 

</di v> 

end Z> 

<div class=" field" > 

<%= f label :name ^><br> 

<%= f.text_field : name %> 

</div> 

<div class=" field" > 

<%- f label :description %><br> 

<%= f . text_area : description %> 

</div> 

<div class=" field" > 

<%= f label :cost ^><br> 

<%- f.text_field : cost %> 

</p> 

<div class=" field" > 

<%- f label : stock Z><br> 

<%= f.text_field : stock %> 

</div> 

<div class="actions" > 


72 https://github.com/bryanbibat/rasm40code/commit/ba9905168d022b014f82dlcb6a4eb661a574ebb4#diff-l 
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<%- f. submit 'Update' %> 
</div> 

<% end %> 


<%= link_to 'Show', ©product %> I 
<%= link_to 'Back', products_path %> 

We did not need to change the declaration for form_for, it already checks the model and determines 
which route to use based on conventions. If the model is new (i.e. create), it will use the products_path. 
Otherwise (i.e. update), it will use product _path. 

For convenience, add the following links to show . html . erb 73 


</p> 

<%= link_to 'Edit this record', edit_product_path(@product) %> <br> 

<%= link_to 'Delete this record', @product, 

:confirm => 'Are you sure?', :method => :delete %> <br> 

<%= link_to 'Back to List of Products', products_path %> 

and index.html. erb 74 


<% ©products . each do I product I %> 

<tr> 

<td><^= product. name %></td> 

<td><^= product . description ^></td> 

<td><^= number_to_currency product . cost, :unit => 'PhP' Z></td> 
<td><^= product . stock ^></td> 

<td><^= link_to 'Show', product_path( product . id) ^></td> 

<td><^= link_to 'Edit', edit_product_path(product) ^></td> 

</tr> 

end %> 


New Controller Actions 

Add the following actions to app/controllers/products_controller .rb 75 : 


73 https://github.com/bryanbibat/rasm40code/commit/ba9905168d022b014f82dlcb6a4eb661a574ebb4#diff-3 
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def edit 

@product = Product . find(params [: id] ) 

end 

def update 

@product = Product . find(params [: id] ) 

if ©product update_attributes(params . require( : product) 

. permit( : name, : description, :cost, :stock)) 
redirect_to ©product, notice: 'Product was successfully updated.' 

else 

render action: "edit" 

end 

end 


Since we’re already familiar with how records are created, this code should be easy to understand. Instead 
of creating records with Product . new, we use Product . find to retrieve the record from the database. The 
@product . update_attributes( ) method is similar to save; it first updates the fields based on the hash 
then validates and saves the object. 




n m foi 

1 

AlingnenaApp 

>^J ! 


C © localhost:3000/products/3 & A 


Product was successfully updated. 

Show Product 

Name: Cola 

Description: fizzy caramel flavored drink 

Cost: PhP25.00 

Stock: 100 

Edit this record 
Delete this record 
Back to List of Products 


And that’s it; we finally created a full table maintenance program without using rails generate 
scaffold. We also learned almost everything that goes on behind the scaffold generated code. 

There are still a bunch of things we add to our maintenance program. We’ll spend the next chapter on 
those things in order to get them out of the way before the next lesson. 


Rails Applications Without Scaffold (part 4: 
RESTFul Routes, Callbacks, Filters, and 
Layout) 

In this chapter, we will be discussing new Rails features from the Model, Controller, and the View that 
can make our Product maintenance program better. 

Reduce Route Entries with Resource-Based Routing 

Creating a new route entry for typical routes sort of defeats the purpose of following Convention over 
Configuration. Fortunately, most of the routing in this program was only done for educational purposes; 
there is a shortcut for telling Rails that a certain resource follows the REST conventions. 

AlingnenaApp : Application routes draw do 
resources : debts 

get 'products/search' => ' products#search ' , :as => ' search_products ' 

resources [products 

end 


Using resources : products adds the following routes and helpers to the system: 


helper 

HTTP verb 

URL 

controller 

action 

use 

products_url, 

GET 

/products 

Products 

index 

Display a list of all 

products_path 
new_product_ur 1 , 

GET 

/products/new 

Products 

new 

products 

Return a form for 

new_product_path 

POST 

/products 

Products 

create 

creating a new 
product 
Create a new 

product_ur 1 , 

GET 

/products/ : id 

Products 

show 

product 

Display a product 

product_path 
ed i t_product_ur 1 , 

GET 

/products/ : id/edit 

Products 

edit 

Return a form for 

ed i t_product_path 

PATCH / PUT 

/products/ : id 

Products 

update 

editing a product 
Update a product 


DELETE 

/products/ : id 

Products 

destroy 

Delete a product 


You can define other routes under the resource by using the collection and member blocks. Use 
collection for routes that affect the entire collection. In our case, we can set the products search as 
a collection route 76 : 
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A1 ingnenaApp : : Appl ication routes draw do 
resources : debts 

resources : products do 
collection do 
get 'search' 
end 
end 

end 

Doing this will also create search_products_xxxx route helpers (we manually set that named route 
before). 

For actions that only affect one resource, use the member option. For example, if we want to add a “suspend” 
action for suspending a specific product (i.e. PUT /products/ : id/suspend), we can use: 

A1 ingnenaApp : Appl ication routes. draw do 
resources : debts 
resources : products do 
collection do 
get 'search' 
end 

member do 

put 'suspend' 
end 
end 

end 

The other options for resource-based routing will be discussed in a later chapter. 

Perform Actions While A Model is Saved using Callbacks 

Aling Nena has dozens, if not hundreds, of different products in stock. If she would encode all of them, 
she might not have time to enter detailed descriptions for each item. To help her in this task, we could 
just set the description to be the same as the product’s name every time she doesn’t enter a description. 

At first glance, the solution to this problem would be in the controller, say, something like this: 

def create 

@product = Product . new(params [: product] ) 

if @product description. blank? 

@product . description = @product . name 
end 
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However, if you would recall our discussion in MVC, most of the business logic must be placed inside the 
model instead of the controller. So how do we set the description without changing the controller? 

For this, we need to understand how to use callbacks. 

Callbacks 

Callbacks are methods called by an Active Record object before and after the object is inserted, updated, 
or deleted from the database. Here is the list of callbacks performed in each of these operations: 


Creating a new record 

Updating a record 

Deleting a record 

before. validation 

before.validation 


before_validation_on_create 

before_validation_on_update 


VALIDATION OPERATION 


after.validation 

after.validation 


before.save 

before.save 


before.create 

before.update 

before.destroy 

INSERT OPERATION 

UPDATE OPERATION 

DELETE OPERATION 

after.create 

after.update 

after.destroy 

after.save 

after.save 



Based on this table, the before_va 1 idation callback is called before the validation of both record creation 
and update. After that, the before_val idation_on_create and before_val idation_on_update are called 
in creation and update, respectively. 

Registering Callbacks 

Registering callbacks is similar to setting validations. Instead of providing fields, however, we provide 
symbols referring to method names. 

# app/models/product . rb 77 


class Product < ActiveRecord : : Base 
validates :name, presence: true 
validates : description, presence: true 

before_val idation : assign_default_description 

private 

def assign_default_description 
if description . blank? 

self description = name 
end 
end 

end 


77 https://github.com/bryanbibat/rasm40code/commit/fl3564c8dccfef50ad8dd7d05a8f3049635f6780#diff-l 
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Here we set the description field of the record before the record is validated (thus preventing an error in 
description validation). 

Note that we set the callback method to be private. This prevents the method from being called outside 
the object. Another thing to note is the use of sel f to denote that we are modifying the instance attribute; 
if we didn’t use self, description, Ruby will think we are simply setting a local variable description. 

Rails Corner - Active Support Ruby Extensions 

In Ruby, there are two ways to check if an object is ni 1 : 
object == nil 
object .nil? 

The nil? method works because nil is an object in Ruby (and not a null pointer) so it has methods of 
its own. Only the nil object returns true when nil? is called. 

In our code above we used “blank?” to check if the string is empty. This method is not part of the 
methods of a String object in the core Ruby library, but an extension done by Rails to the String object 
via the Active Support libraries. 

Thanks to the dynamic nature of Ruby, other libraries can choose to extend the functionality of 
core classes. It might look dangerous, but when done right, the new methods can make coding more 
convenient to developers. 

We’ll discuss in a later chapter some other extensions Rails made to Ruby. 
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Ruby Corner - Private Methods 

Methods inside a Ruby class are public by default. You can define method visibility by using public, 
private, and protected keywords: all methods defined below them will use the said keyword for 
visibility. 

In our case above, the method assign_default_description has become private because it is declared 
below the private keyword. 


Limiting User Access with Filters and Authentication 

Aling Nena wants her customers to see the list of available products in her store. However, she doesn’t 
want them to create and edit the products, or worse, delete the products. In short, she wants to add an 
authentication mechanism in her site. 

Controller Filters 

Authentication is like validation; we want to validate whether the user has permission to do something 
in our application. Unlike validation, it is not done in the Model level but in the Controller level, with the 
help of the controller filters. 

Controller filters are more like callbacks than validations. They are methods that we define to be executed 
before actions (using before_action) or after actions (using after_action). The syntax is also similar: 

# app/control lers/products_control ler . rb 78 


class ProductsController < Appl icationControl ler 
before_action : check_i f_al ing_nena 


private 

def check_if_aling_nena 
# checking here 
end 

end 

In this case, the method check_if_aling_nena is called before every action in the Products controller. If 
we want to limit the actions where the filter is applied, we can use the : only option. 

before_action :check_if_aling_nena, :only => [:new, :create, :edit, :update, :destroy] 

It might make sense to use the : except option here, though. 
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before_action :check_if_aling_nena, :except => [: index, :show, :search] 

One important thing about before_action methods is that the processing will not continue to the action 
if the method renders or redirects. Here’s one way to test our new filter, by kicking everyone back to the 
list products page regardless of who they are 79 : 

def check_i f_al ing_nena 

redirect_to products_path, notice: "You must be Aling Nena to access this page." 
end 


|V AlinanenaApp 

“Hfl 



^ # C © localhost: 3000/products 

☆ 

1 A, 

You must be Aling Nena to access this page. 



Search by product name: |~ 


Search 


Listing Products 




Name Description 

Cost Stock 



test product 1 test description 1 

PhPl.ll 10 

Show Edit Destroy 1 

1 test product 2 <b>test description 2</b> PhP2.22 20 

Show Edit Destroy 1 

| Create a new Product 



II 


(You may want to change that flash message to : alert, just don’t forget to add the code to index that 
would display the message.) 

HTTP Authentication 

Having verified that the filter works, let’s now add the authentication. 

Rails has built in methods that make applying basic HTTP authentication easy. Here’s the code to apply 
that authentication 80 to our Product maintenance program (you can change the username and password 
as you like): 

def check_i f_al ing_nena 

authenticate_or_request_with_http_basic( "Products Realm") do I username, password I 
username == "admin" and password == M sTr0NG_p4$swOrD" 
end 
end 

You should see browser-specific pop-up prompting you for credentials: 

7s, https://github.com/bryanbibat/rasm40code/commit/fl3564c8dccfef50ad8dd7d05a8f3049635f6780#diff-0 

so https://github.com/bryanbibat/rasm40code/commit/d93833071dl55a8cela4a65b7dad8090a973fa29 
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X 

i 



[«- o 

© localhost 3000/products & 



The server localhost:3000 at Products 
Realm requires a username and password. 


User Name: 
Password: 


Cancel 


Entering the credentials will let you proceed to the pages. Since HTTP authentication is supported by all 
browsers, the server knows if you already provided your credentials so you don’t have to re-enter it again 
when you enter the other actions in the program. 

Pressing Cancel will redirect you to an error page: 


a 

"I (Tirol 

i 



r c 

© localhost:3000/products/new & 

' 


HTTP Basic: Access denied. 


HTTP Authentication is the most basic of all authentications available to Rails. For larger applications 
with many users, you’re better off with full-fledged authentication solutions like the Authlogic or Devise 
gems. 

Layouts and Rendering in the View 

Asset Tags 

Static files in our web application are stored in the publ ic folder. Since this folder is mapped directly to 
the application root, going to http: //locahost : 3000/ will open publ ic/index . html . 

However, certain assets like JS, CSS, and image files are stored in the app/assets folder so that they can 
be processed by Rails’s Asset Pipeline. We’ll discuss the Asset Pipeline in further detail much later under 
the Deployment chapter; in the meantime, we’ll briefly show the view helper methods for stylesheets, 
JavaScript files, and images. 

By convention, stylesheets, images, and JavaScript files are stored in the app/assets/stylesheets, 
app/assets/ images, and app/assets/ javascripts folder, respectively. Rails provides view helpers called 
asset tags for linking to these files. 
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We can use stylesheet_link_tag to link to CSS files under the app/assets/stylesheets folder. The 
syntax is as follows: 

stylesheet_l ink_tag( *sources, options = {} ) 

You can pass one or more stylesheets to the method: 

<%= stylesheet_l ink_tag( "main" ) %> 

<%= stylesheet_l ink_tag( "sidebar" , "admin") %> 

The code above creates the following links if the linked files are missing from the app/assets/stylesheets 
folder: 

<link href="/stylesheets/main . css" media="screen" rel="stylesheet" type="text/css . . . 


<link href="/stylesheets/sidebar . css" media=" screen" rel="stylesheet" type="text/ . . . 

<link href="/stylesheets/admin . css" media="screen" rel="stylesheet" type="text/ . . . 

Rails will fall back to the publ ic/* folder in case the stylesheet is missing from the app/assets/* folder. 

On the other hand, if you do use the Asset Pipeline (under development mode), here’s what it will look 
like: 


<link href="/assets/main . css?body=l " media=" screen" rel="stylesheet" type="... 

<link href="/assets/sidebar . css?body=l " media="screen" rel="sty lesheet" type=" . . . 
<link href="/assets/admin . css?body=l " media="screen" rel="stylesheet" type=" . . . 

Before we go into the Asset Pipeline discussion, just note that you can also use relative paths: 

<%= stylesheet_l ink_tag( "red/main" ) %> 

<link href="/stylesheets/red/main . css" media="screen" rel="stylesheet" type... 
You can also use absolute or external paths: 

<%= stylesheet_l ink_tag( "http : //example . com/main" ) %> 


<link href="http : //example . com/main . css" media="screen" rel="stylesheet" ... 

You can also override the link attributes by adding them as options. For example, you can change the 
media from screen to print using the following: 

<%= sty lesheet_l ink_tag( "main" , { : media => "print"}) %> 

Now to discuss the Asset Pipeline. The main reason behind the Asset Pipeline is to preprocess CSS and JS 
files, and one of those preprocessing methods is to concatenate the said files into single file. Concatinating 
CSS and JS will reduce the amount of requests to your server, and this can significantly improve loading 
times especially if you have a lot of files. 

We can see this happening in the default app/assets/stylesheets/appl i cat ion .css file: 
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/* 

* This is a manifest file that'll be compiled into application .css, which will... 

* listed below. 

* 

* Any CSS and SCSS file within this directory, lib/assets/stylesheets, vendor/... 

* or vendor/assets/stylesheets of plugins, if any, can be referenced here using. . . 

* 

* You're free to add application-wide styles to this file and they'll appear... 

* compiled file, but it's generally better to create a new file per style scope. 

* 

*= require_sel f 
*= require_tree . 

*/ 

We shal see a bit later that this file is referenced in all our pages via a <%= stylesheet_l ink_- 
tag(" application") %> call. When the asset is accessed, Rails will process the comments in the CSS 
file; Rails will insert the contents of the appl i cat ion . css file in the = require_sel f comment location, 
then it will insert all of the CSS files in the current directory at the = require_tree . comment. 

Let’s move on to to JS. The asset tag for JavaScript is javascript_include_tag and it behaves the same 
way as the stylesheet_l ink_tag. Here’s an example of linking to an asset in the publ ic/javascripts 
folder: 

<%= javascript_include_tag(main) %> 

=> <script type="text/javascr ipt" src="/javascr ipts/main . js"> </script> 

Similar to the stylesheet_l ink_tag, linking to an asset in the app/assets/javascripts folder will make 
Rails process its comments to create a concatenated JS file. Open app/assets/ j avascr i pts/app 1 i cat i on . j s 
to see the default JS file: 

// This is a manifest file that'll be compiled into application . js, which will... 

// listed below. 

// 

//Any JavaScript/Coffee file within this directory, lib/assets/ javascripts, ... 

// or vendor/assets/ javascripts of plugins, if any, can be referenced here using. . . 

// 

// It's not advisable to add code directly here, but if you do, it'll appear at. . . 

// compiled file. 

// 

// Read Sprockets README (https://github.eom/sstephenson/sprockets#sprockets-di .. . 

// about supported directives . 

// 

//= require j query 
//= require jquery_ujs 
//= require turbolinks 
//= require_tree . 
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As you can see, jQuery and Turbolinks are added before the JavaScript files in the same folder. We shall 
discuss both under the Ajax chapter. 

For images, the asset tag is image_tag. The basic use is similar to the two previous asset tags. Here’s what 
it would look like if the file exists in the app/assets/ images folder: 

<%= image_tag "banner. png" %> 

=> <img src="/assets/banner . png" /> 

In addition to the HTML attributes that you can set in the options hash parameter, image_tag has the 
following special options: 

• : alt- If no alt text is given, the file name part of the source is used (capitalized and without the 
extension) 

• :size - Supplied as “{Width}x{Height}”, so “30x45” becomes width=”30” and height=”45”. :size 
will be ignored if the value is not in the correct format. 

Layouts 

We now know how to link to CSS files in our pages but having to add <%= stylesheet_link_tag 
"scaffold" %> (the CSS used in Debts) to all of our pages can be a hassle, not to mention that it violates 
the DRY ( Don’t Repeat Yourself) principle that we’ve been following as we applied Convention over 
Configuration to our program. There must be a way for us to apply HTML code to all of our pages. 

Thankfully, Rails already provides a way to do that through layouts. 

Layouts, as you may have guessed, provide the general layout for our views. Rails combines the view and 
the layout when rendering the page to the user. An example of a layout is the default layout generated 
when we created our application, app/views/layouts/appl ication . html . erb: 


< ! DOCTYPE html > 

<html> 

<head> 

<title>Al ingnenaApp</title> 

<%= stylesheet_l ink_tag "application”, media: "all”, 

"data-turbol inks-track" => true %> 

<%= javascr ipt_include_tag "application", "data-turbol inks-track" => true %> 
<%= csrf_meta_tags %> 

</head> 

<body> 

<Z= yield 


</body> 
</html > 


The yield section defines where the view will be inserted upon rendering. You can also use multiple 
yielding regions: 
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<html> 

<head> 

<%= yield : head %> 

</head> 

<body> 

<£= yield £> 

</body> 

</html > 

To render content in a named yield, you use the content_for method: 

<% content_for :head do %> 

<title>A simple page</title> 

<Z end %> 

<p>Hello, Rails!</p> 

This would result in: 

<html> 

<head> 

<title>A simple page</title> 

</head> 

<body> 

<p>Hello, Rails!</p> 

</body> 

</html > 

By default, Rails checks the app/views/ layouts directory for a layout that matches the name of the 
controller. If the layout isn’t found, Rails will try app/views/layouts/appl ication . html . erb. 

There are two other ways to define layouts. First is through the controller: 

class ProductsController < Appl icationControl ler 

before_action :check_if_aling_nena, :except => [: index, :show, :search] 

layout "main" 


This will apply app/views/layouts/main . html . erb to all actions in Products. 
Layouts are shared downwards in the hierarchy, so applying 
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class ApplicationController < ActionControl ler : : Base 

# Prevent CSRF attacks by raising an exception . 

* For APIs, you may want to use : nul l_session instead. 
protect_from_forgery with: exception 

layout "main" 


will set the layout of every controller to app/views/layouts/main . html .erb because all controllers (at 
least the ones generated by rails generate controller and scaffold) are subclasses of ‘Application- 
Controller. 

Another way of setting the layout is through the render method. Before, the only option we discussed 
for render is : action, so now we introduce a new option, : layout, which lets you define the layout of a 
rendered view: 

render : layout => "main", : action => "new" 

You can also remove a layout by setting it to ‘false. For example: 
render : layout => false, :action => "new" 

When multiple layouts are applied to a view, more specific layouts always override more general ones. 
For example: 

class ProductsController < ApplicationController 
layout "main" 
def show 

@product = Product . find(params [: id] ) 
render : layout => false 
end 


No layout is rendered for the show action above. (Recall that the : action option is automatically set by 
Rails according to the action name if it’s not defined.) 

Partial Templates 

When you look at app/views/products/new. html .erb and app/views/products/edit . html . erb, you 
will notice that both share almost the same code for the form. We can eliminate this redundancy by using 
partial templates, better known as partials. 

Partials are fragments of pages that can be called by other pages. We use the render method to tell rails to 
render a partial inside a view. For example, if we call the following inside app/views/products/new . html . erb 


<%- render( {: partial => ' form ' } ).£> 
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The call will insert the contents of app/views/products/_form . html . erb at that line inside the view. 

We can use the : locals option to pass local variables to the partial. For example, we can eliminate the 
redundancy between new and edit by modifying the views: 

# new. html .erb 81 

<hl>New Product</hl> 

<%= render( {: partial => "form", 

: locals => { : product => @product, : button_label => "Create" } }) %> 

<%= link_to 'Back 1 , products_path %> 

# edit . html . erb 82 

<hl>Edit Product</hl> 

<%= render( { : partial => "form", 

: locals => { : product => ©product, : button_label => "Update" } }) %> 

<%= link_to 'Show Details', ©product %> I 
<%= link_to 'Back to List', products_path %> 

and creating a new partial app/views/products/_form . html . erb 83 : 


<%= form_for product do If I %> 

<% if product . errors . any? %> 

<div id="error_explanation" > 

<h2><^= plural ize product . errors . count, "error" %> prohibited this product from 
being saved : </h2> 

<ul> 

<% product . errors . ful l_messages . each do I msg I %> 

<li><%= msg %></li> 

<% end %> 

</ul> 

</di v> 

end Z> 

<div class=" field" > 

<%= f label :name ^><br /> 

<%- f.text_field : name %> 

</div> 

<div class=" field" > 

<%= f label :description %><br /> 

<%~ f . text_area : description %> 

81 https://github.com/bryanbibat/rasm40code/commit/c95dl239469618a79011dcc944dddc8b0cel607a#diff-2 

s2 https://github.com/bryanbibat/rasm40code/commit/c95dl239469618a79011dcc944dddc8b0cel607a#diff-l 

s3 https://github.com/bryanbibat/rasm40code/commit/c95dl239469618a79011dcc944dddc8b0cel607a#diff-0 


Rails Applications Without Scaffold (part 4: RESTFul Routes, Callbacks, Filters, and Layout) 


90 


</div> 

<div class=" field" > 

<%= f label :cost %><br /> 
<%~ f . text_f ield : cost %> 
</div> 

<div class=" field" > 

<%= f. label : stock %><br /> 
<%- f.text_field : stock %> 
</div> 

<div class="actions" > 

<%= f submit button_label %> 

</div> 

end Z> 


In this case, the product local variable was derived from the ©product instance variables, while the 
button_label was supplied in the hash. 

All partials have a local variable with the same name as the partial and you can pass an object to this by 
using the : object option. In other words, suppose we make a copy of the _form partial at _product_- 
form . html . erb, and we replace the first line with: 

<%= form_for product_form do If I %> 

We would be able to do this in edit. html. erb: 

<%= render( {: partial => "product_form" , 

: object => @product, 

: locals => { : button_label => "Update" } } ) %> 

The instance variable is placed inside the product_form variable. 

We can also use partials to render a collection of objects using the : col lection option. For instance, we 
can replace the iteration inside app/views/products/ index, html . erb 84 with the following: 


<thead> 

<tr> 

<th>Name</th> 

<th>Descr iption</th> 

<th>Cost</th> 

<th>Stock</th> 

</tr> 

</thead> 

<tbody> 

<%= render ({ : partial => "item", : col lection => ©products }) %> 
</tbody> 

</table> 


s4 https://github.com/bryanbibat/rasm40code/commit/ed8bfd469d5dle5c234d5a2b01dle0e074f9elfd#diff-l 
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And create a new partial, _item . html . erb 85 : 

<tr> 

<td><^= item. name %></td> 

<td> <%= item . description ^></td> 

<td><%= number_to_currency item cost, unit: ' PhP ' %></td> 

<td > <%= item. stock ^></td> 

<td> <%- link_to 'Show', item ^></td> 

<td><%- link_to 'Edit', edit_product_path( item) %></td> 

</tr> 

The page would still display as it was originally displayed. Each item in the array is placed in a local 
variable that shares the same name as the partial. In this case, the partial and variable name is item. 

We can even define a spacer template for the collection: 

<%= render({ :partial => "item”, :collection => ©products, 

: spacer_template => "hr" }) %> 

Here’s a sample _hr . html . erb 86 : 

<tr> <td colspan="7" > <hr> </td> </tr> 

There is also a shorthand for partials. Assuming @product a single Product object the following code: 
<%= render({ : partial => @product } ) %> 

will render _product.html .erb and pass ©product as the value of the local variable product. Similarly, 
assuming ©products is a collection of Product objects, the following code: 

<%= render({ : partial => ©products }) %> 

will render the partial _product . html . erb for each Product object inside the collection, passing the object 
to the local variable product. 

Using a collection with different object types can produce polymorphic results. For example, if employeel 
and employee2 are Employee objects, while customerl and customer2 are Customer objects, the following 
call: 


<%= render({ : partial => [customerl, employeel, customer2, employee2] } ) %> 


will call the following partials, either _customer . html . erb 


85 https://github.com/bryanbibat/rasm40code/commit/ed8bfd469d5dle5c234d5a2b01dle0e074f9elfd#diff-0 

8s https://github.com/bryanbibat/rasm40code/commit/c4646a715af2bfae9e0b715416ef2add4c297e20#diff-0 
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<p>Name: <%= customer name %></p> 
or _employee . html . erb: 

<p>Name: <%= employee name %></p> 
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Shortcut Corner 

Don’t forget you can always remove the parenthesis from a method call, or the curly braces from a 
hash if it’s the last hash argument for a method. There are also short-hand default versions of rendering 
partials. Here are some examples: 

<%- render — : partial — " form" , — 

: locals ~> — { — : product -> ©product, — : button_labol -> — "Update" — } %> 

<%= render partial: "form", locals: { product: ©product, button_label : "Update" } %> 

<%= r c nd c r({ — : partial ~> ©products }) %> 

<%= render ©products %> 

There’s also a much shorter form for render : partial => : locals => {}: 

<%= r e nd e r partial : — " form" , — locals : — [ product: ©product, button_lab e l : — "Updat e " — } %> 

<%= render "form", product: ©product, button_label : "Update" %> 


Associations 


When you’re working with RDBMSs, you’re bound to encounter cases where you have to handle 
relationships between tables. One-to-many relationships are common, though you might see many-to- 
many and one-to-one relationships from time to time. 

Does Rails support these relationships? 

No and yes. 

Rails does not support the various relationship implementations between database vendors. You will have 
to tweak your migrations to call specific DDL commands in order to set them up (this is outside the scope 
of this training course). 

Rails, however, has its own database-agnostic way of handling entity relationships. In this chapter, we 
will discuss how to these various relationships are coded in Rails. 

Migrations for Associations 

If you would recall in our previous lesson, by default all tables in a Rails application use “id”, an auto- 
incrementing integer field, as their primary key. In the context of associations, Rails uses this convention 
to link tables in a system. 


Rails Conventions 

If a table refers to another table, say an Employee belonging to a Department, the former must have a 
field that refers to the latter. This foreign key reference field should be an integer field in the format 
[model_name] _id. 

In the Employee-Department case, our Employees table should have a integer field named department_- 
id. This field would contain the id of the Department where the Employee belongs to. 


When generating the migration for a foreign key reference field, you can specify the field normally e.g. 

$ rails generate migration Employee name: string department_id : integer 
Or you can make the abstraction clearer by using the : references data type: 

$ rails generate migration Employee name: string department : references 

This migration will still generate the same field as the previous migration. Note the lack of _id in the 
references argument. 

Defining Associations in Models 

Had you used rai Is generate scaffold or rai Is generate model instead of migration, you will notice 
that the model generated has a belongs_to call: 
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class Employee < Act i veRecord :: Base 
belongs_to : department 

end 

Again, another human-readable declaration in Rails: it simply tells Active Record that each Employee 
record belongs to a Department record. 

belongs_to 

For every belongs_to call inside the model, Active Record generates some instance methods for the class. 
In the Employee-Department case, these methods are 

• employee. department - returns the Department object associated to the Employee. This is cached 
so if you want to reload the list, just passtrue to the method. Can also be used to assign a Department 
to the Employee e.g. employee . department = some_department 

• employee.build_department(attribute_hash) - basically a shorthand for employee . department 
= Department . new(attribute_hash). Also returns the newly created Department. 

• employee . create_department(attr ibute_hash) - same as bui ld_department, the only difference 
is the new object is saved (assuming it passes validations, of course). 

Even with these methods, using the department_id for defining associations is still valid. The following 
will work: 

department = Department . find_by_name( "Accounting" ) 
employee . department_id = department id 

but it’s still better to use an approach with a clearer abstraction: 

employee . department = Department . find_by_name( "Accounting" ) 

not to mention coding the bui ld_xxxx and create_xxxx methods manually will take at least 2 more lines 
of code than just calling those methods. 

One-to-One Relationships 

With the belong_to declaration in one model, we can define the nature of the association in the target 
table. Let’s start with the one-to-one association. 

For this tutorial, we’re going to expand Aling Nena’s system by adding a Purchase entity whose records 
refer to a single purchase of items from a supplier. We’re going to have an Invoice record for each Purchase, 
and this one-to-one relationship will be the basis of this tutorial. 

First, let’s setup the Purchase and Invoice entities with scaffold scripts: 
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$ rails generate scaffold purchase description : text del ivered_at : date 
$ rails generate scaffold invoice purchase : references reference_number : string 
$ rake db: migrate 

This should make working maintenance programs for each entity. When you look at the new and edit 
views of the Invoice program, however, you will see that it uses a text_field for the purchase. This 
is inappropriate: not only does it force the user to know the Purchase while editing the field, it also 
won’t work because the data types don’t match (text_f ield is String, while the purchase field requires a 
Purchase). 

Drop Down List 

A better approach would be to provide a drop-down field containing a list of available Purchases. The 
form helper for drop-down lists is col lection_select 

col lection_select(object, field_name, collection, value_method, text_method, 
options = {}, html_options = {}) 

* or the form_for shortcut 

f . col lection_select( f ield_name, collection, value_method, text_method, 
options = {}, html_options = {}) 

The object, f ield_name, and options field are just the same as in our basic input field text_f ield, with 
the options separated from the html_options. 

The collection is a list of items where the value and the text are derived from, while the value_method 
and text_method determines the names of the methods to call for the value and text. For example, we 
have the following list of Purchases: 


i 

AlingnenaApp \<C 

r 

© localhost: 3000/purchases & 

- 


Listing purchases 


Description Delivered at 

Cola delivery 2011-01-02 Show Edit Destroy 
Soap delivery 2011-01-03 Show Edit Destroy 
Candy delivery 2011-01-04 Show Edit Destroy 

New Purchase 


Replacing the purchase field in app/views/invoices/_form . html . erb 87 to 


s7 https://github.com/bryanbibat/rasm40code/commit/731bb20bf488f6b68cb6141d76f84fa0bcee5814 


Associations 


97 


</div> 

<% end %> 

<div class=" field" > 

— <%- f. label — :purchase_id %><br> 

— <%= f.t e xt_fi c ld — :purchas e _id %> 

<%= f. label : purchase_id, "Purchase" %><br> 

<%= f . collection_select :purchase_id, Purchase all, :id, :description %> 

</div> 

<div class=" field" > 

<%= f. label : reference_number %><br> 

<%= f.text_field : reference_number %> 

</div> 


will result in the following HTML code: 


<div class=" field" > 

< label for=" invoice_purchase_id" >Purchase</label > <br /> 
<select id=" invoice_purchase_id" name=" invoice [purchase_id] " > 
<option value="l " >Cola del ivery</option> 

<option value="2" >Soap del ivery</option> 

<option value="3" >Candy del ivery </option> 

</select> 

</div> 


There are three available options in collection_select: 

• : include_blank - adds a blank entry at the top of the list. Can be the text of the entry (e.g. “none”) 
or true (which will just put a blank entry). 

• : prompt - just like include_blank, but has a different purpose: to prompt the user to select one item 
in the list. When set to true, the text used is “Please select”. Setting this option will not add validation 
for checking if the user chose a value from the list. Setting this option along with : include_blank 
will add 2 blank list entries in the list, one for each call with the prompt on top. 

• : disabled - contains a list of items from col lection that should be disabled from the list. In the 
case of col lection_select, we can use a Proc to determine which should be disabled. For example, 
to disable all Purchases that would be delivered in the future, we can set: 


<%= f . col lection_select : purchase_id, Purchase . al 1 , :id, : description, :prompt => true, 
: disabled => lambda { I purchase | purchase . del ivered_at > Date . today } %> 

Custom Helpers 

After creating the Invoice for the “Cola delivery”, we see a problem in the Show Invoice page: 
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— n 

” 1 

) AlingnenaApp 

^ 


C O localhost:3000/invoices/1 'uT ^ 


Invoice was successfully created. 
Purchase: #<Purchase:0xa465820> 
Reference number: 0000000000000128X 
Edit | Back 


What is displayed is the internal representation of the Purchase object. Sure, we can remedy this by 
replacing the code with: 


<p> 

<strong> Purchase : </strong> 

— <%= ^invoic e . purchas e %> 

<%= @invoice . purchase description %> 

</p> 

But what if we had created an Invoice without a Purchase? 



We get Ruby’s equivalent to a Null Pointer Exception. 

There are some ways to remedy this problem. The most obvious would be to make the field mandatory 
through validations. But for entities that allow that foreign key field to be empty, we need to directly 
address the problem. 

One way would be to add a special method inside the model. For example: 
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class Invoice < ActiveRecord : : Base 
belongs_to : purchase 

def display_purchase 

return purchase description unless purchase nil? 

"(no Purchase set)" 
end 
end 

Then just call @invoice . display_purchase from the view. This approach is legal and is actually the 
preferred approach For educational purposes, however, let’s move the logic to the view instead: 


<P> 

<strong>Purchase : </strong> 

<% unless @invoice . purchase . ni 1 ? %> 

<%= §invoice . purchase . description %> 

<% else 

(no Purchase set) 

<% end %> 

</p> 

Our problem this time is that we’re adding 5 lines of processing code to our view for a simple task. If we 
do this a lot, our view would look cluttered and may bring back bad memories of old JSP, ASP, PHP code 
from older developers. We can take out this code from our views through the helper files. 

The helper files are located at the app/helpers folder. These are modules where you can add methods 
that you would use in your views. One helper is created per controller if you generated them throughrails 
generate controller or scaffold. We can move our logic from the view into the helper by adding the 
following lines to app/helpers/invoices_helper.rb 88 : 

module InvoicesHelper 

def display_purchase( invoice) 
unless invoice purchase nil? 

invoice purchase description 
else 

"(no Purchase set)" 
end 
end 
end 

and just call the helper in our view 89 : 


88 https://github.com/bryanbibat/rasm40code/commit/48a05el84f9df649f238789c4db9b0dldd2db378#diff-0 

s, https://github.com/bryanbibat/rasm40code/commit/48a05el84f9df649f238789c4db9b0dldd2db378#diff-l 
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<p> 

<strong>Purchase : </strong> 

<%= display_purchase(§invoice) %> 

</p> 

All helper methods from all helpers are available to all views. The file scheme used is just for developers 
to classify the helpers according to the program they are used. 

Helpers are usually used for generating markups. For instance, we want to have the Purchase field to have 
a link to the original purchase, we can use 90 : 

module InvoicesHelper 

def display_purchase( invoice) 
unless invoice . purchase nil? 

link_to invoice purchase description, invoice. purchase 

else 

"(no Purchase set)" 

end 

end 

end 

You can’t do this inside the model, and this gives helpers an advantage over the model approach. 

has_one 

We’ve already associated Invoice with Purchase but not the other way around. In order for us to be able to 
call methods like ©purchase . invoice, we must first declare the association in the Purchase model. Given 
that we’re using a one-to-one relationship, the association declaration will be 91 : 

class Purchase < ActiveRecord : : Base 

has_one : invoice 
end 

With the has_one method declared, we can now call the following methods in Purchase: 

• purchase. invoice, purchase. invoice^ 

• purchase . bui ld_invoice, purchase . create_invoice 

Yes, these are the same methods as the ones in the belong_to model. 

You can provide options in the : has_one declaration. Here are a few: 

• : dependent - provides the behavior when this model is deleted i.e. cascading delete options. Setting 
it to : nul 1 i fy simply sets the foreign key reference in the other entity to NULL. Using : destroy will 
call the : destroy of the other entity, while using : delete will simply delete the related record via 
SQL. 

• : validate - when set to true, validates the associated object upon save of this object. By default 
this is false. 

9o https://github.com/bryanbibat/rasm40code/commit/0d72ca97ed70fbf83f385568el7eeea245bf5fac 

91 https://github.com/bryanbibat/rasm40code/commit/lcaa718983ca5d59el9c83509627cfa7d87fe6f7 
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Nested Routes and Singular Resources 


One problem with our current Purchase-Invoice scheme is that you could assign one Purchase to two 
Invoices. 




n — n 


yg AlmgnenaApp 



c © localhost:3000/invoices & ^ 


Listing invoices 

Purchase Reference number 

Cola delivery 0000000000000128X Show Edit Destroy 
Cola delivery 0000000000000124X Show Edit Destroy 

New Invoice 


Calling ©purchase . invoice on this will return only the first related Invoice. 


x - n 


) AlmgnenaApp 


O localhost: 3000/purchases/1 & | 


Description: Cola delivery 
Delivered at: 2011-01-02 

Invoice Reference Number: 0000000000000128X 

Edit | Back 


The root cause of this problem is that we’re creating Invoices outside the context of the Purchase. Wouldn’t 
it make more sense to be able to go to http : //localhost : 3000/purchases/l/invoice/new to create the 
invoice for the first Purchase that what we’re currently doing right now? 

We can do this with the help of 2 new routing concepts: the singular resource and nested resources. 

The singular resource just like our typicalresources call, but instead of dealing with multiple records, it 
deals with only one object. For example, adding the singular resource route: 


resource : platform 


assumes that we only have one Platform entity for the entire system (note we used resource instead of 
resources). The generated routes in this instance is: 


helper 

HTTP verb 

URL 

controller 

action 

use 

platform_url, 

GET 

/platform 

Platforms 

show 

Display the platform 

platform_path 
new_p 1 at f or m_ur 1 , 

GET 

/platform/new 

Platforms 

new 

Return a form for 

new_p 1 at f or m_path 

POST 

/platform 

Platforms 

create 

creating the new 
platform 

Create the new platform 
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helper 

HTTP verb 

URL 

controller 

action 

use 

edit_platform_ur 1, 

GET 

/platform/edit 

Platforms 

edit 

Return a form for 

edit_platform_path 

PUT 

/platform 

Platforms 

update 

editing the platform 
Update the platform 


DELETE 

/platform 

Platforms 

destroy 

Delete the platform 


To use this in the Purchase-Invoice relationship, we’ll have to set the Invoice as a singleton child of each 
Purchase entity by nesting aresource call under the resources call 92 : 

AlingnenaApp : Application routes draw do 

resources : purchases do 
resource : invoice 
end 

resources : debts 

resources : products do 
collection do 
get 'search' 

end 

end 

end 


This will create the following additional routes: 


helper 

HTTP verb 

URL 

controller 

action 

purchase_invoice_ur 1, 

GET 

/purchases/ : purchase_- 

Invoices 

show 

purchase_invoice_path 
new_purchase_i nvoice_ur 1 , 

GET 

id/invoice 

/purchases/ : purchase_- 

Invoices 

new 

new_purchase_invoice_path 

POST 

id/invoice/new 
/purchases/ : purchase_- 

Invoices 

create 

edit_purchase_invoice_url, 

GET 

id/invoice 

/purchases/ : purchase_- 

Invoices 

edit 

ed i t_pur chase_i n vo i ce_path 

PUT 

id/ invoice/edit 
/purchases/ : purchase_- 

Invoices 

update 


DELETE 

id/invoice 

/purchases/ : purchase_- 

Invoices 

destroy 


id/invoice 


We have to change the logic of our Invoice program to handle these changes. First, the controller 9 


92 https://github.com/bryanbibat/rasm40code/commit/52c31el0189e82el8ffbeeb67613eclcc56bfllc#diff-6 

93 https://github.com/bryanbibat/rasm40code/commit/52c31el0189e82el8ffbeeb67613eclcc56bfilc#diff-0 
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class InvoicesController < Appl icationControl ler 

before_action : set_invoice, only: [:edit, : update, : destroy] 

def show 

# we'll integrate the Invoice details in the Show Purchase screen 

redirect_to purchase_path(params [ : purchase_id] ) 

end 

def new 

©purchase = Purchase. find(params[ :purchase_id] ) 

@invoice = ©purchase . bui ld_invoice 

end 

def edit 

end 

def create 

©purchase = Purchase . find(params [: purchase_id] ) 

@invoice = ©purchase bui ld_invoice( invoice_params) 
if ©invoice . save 

redirect_to ©purchase, notice: 'Invoice was successfully created.' 

else 

render action: "new" 

end 

end 

def update 

if ©invoice update_attr ibutes( invoice_params) 

redirect_to ©purchase, notice: 'Invoice was successfully updated.' 

else 

render action: "edit" 

end 

end 

def destroy 

@invoice . destroy 

redirect_to ©purchase, notice: 'Invoice was successfully deleted.' 

end 


private 

# Use callbacks to share common setup or constraints between actions. 
def set_invoice 

©purchase = Purchase . find(params [: purchase_id] ) 

@invoice = ©purchase . invoice 

end 

# Never trust parameters from the scary internet, only allow the white list through. 
def invoice_params 
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params . require( : invoice) . permit ( : reference_number ) 

end 

end 

In case you’ve forgotten how routes work, the : purchase_id parameter is derived from the URL. 
Here’s the changes we’ll need for the views. Let’s modify Invoice’s views: 

# app/views/invoices/new . html . erb 94 

<hl>New Invoice</hl> 

<%= render 'form', purchase: ©purchase, invoice: (©invoice %> 

<%= link_to — ' Back ' , — invoic e s_p a th %> 

# app/views/invoices/edit . html . erb 95 
<hl>Editing Invoice</hl> 

<%= render 'form', purchase: ©purchase, invoice: ©invoice %> 

<%= link_to — 'Show', ©invoic e %> — f 
<Z~ link_to — ' Back ' , — invoiccs_path %> 

# app/views/invoices/_form . html . erb 96 

<%= form_for invoice, url : purchase_invoice_path(purchase) do If I %> 

<% if invoice . errors . any? %> 

<div id="error_explanation" > 

<h2><%= plural ize( invoice . errors . count, "error") %> prohibited this invoice 
from being saved :</h2> 

<ul> 

<% invoice . errors . ful l_messages . each do I msg I %> 

<li><^= msg ^></li> 
end £> 

</ul> 

</di v> 

<% end %> 


<P> 

<label>Purchase</label> <br> 

<%= purchase description %> 

</p> 

<P> 

<%= f. label : reference_number ^><br> 

94 https://github.com/bryanbibat/rasm40code/commit/52c31el0189e82el8ffbeeb67613eclcc56bfllc#diff-4 

95 https://github.com/bryanbibat/rasm40code/commit/52c31el0189e82el8ffbeeb67613eclcc56bfllc#diff-3 

96 https://github.com/bryanbibat/rasm40code/commit/52c31el0189e82el8ffbeeb67613eclcc56bfllc#diff-2 
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<%= f . text_f ield : reference_number %> 

</p> 

<P> 

<%= f. submit %> 

</p> 

<Z end %> 

<%= link_to 'Back', purchase %> 

Here’s Purchase’s app/views/purchases/show . html . erb 97 : 


< hi > Purchase Details</hl> 

<P> 

<strong>Description : </strong> 

<%= §purchase description %> 

</p> 

<p> 

<strong>Del ivered at:</strong> 

<%= §purchase delivered_at %> 

</p> 

<% display_invoice @purchase %> 

<%= link_to 'Edit', edit_purchase_path(@purchase) %> I 
<%= link_to 'Back', purchases_path %> 

We used a scriptlet instead of an expression so that we could use theconcat method (similar to PHP’s 
print or Servlets’ out. print In) in our helper to add multiple elements in the view. Here’s the helper 
method: 

# app/helpers/purchases_helper . rb 98 


module PurchasesHelper 

def display_invoice(purchase) 
unless purchase. invoice nil? 

concat(raw " <p> <strong> Invoice Reference Number : </strong>\n" ) 
concat(link_to @purchase . invoice reference_number, 
edit_purchase_invoice_path(§purchase) ) 
concat(raw "</p>") 
concat(raw "<p>") 

concat(link_to "Delete Invoice", purchase_invoice_path(@purchase) , 

: confirm => "Are you sure?", : method => : delete) 
concat(raw "</p>") 
else 

concat(raw "<p>") 

concat(link_to "Create Invoice", new_purchase_invoice_path(@purchase) ) 

97 https://github.com/bryanbibat/rasm40code/commit/52c31el0189e82el8ffbeeb67613eclcc56bfllc#diff-5 

98 https://github.com/bryanbibat/rasm40code/commit/52c31el0189e82el8ffbeeb67613eclcc56bfllc#diff-l 
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concat(raw "</p>") 
end 
end 
end 


Our new Purchase-Invoice program should work properly now: 




- □ 

' 1 

i AlingnenaApp 

| 


C O localhost:3000/purchases/2 ft A 


Description: Soap delivery 
Delivered at: 2011-01-03 
Create Invoice 
Edit | Back 




— n 

" 

AlingnenaApp 

X ^ 


C © localhost:3000/purchases/2/ ft \ 


New invoice 

Purchase 
Soap delivery 

Reference number 


Create 


Back 


x - n 


[j AlingnenaApp 



O localhost:3000/purchases/2 ft 

* 


Invoice was successfully created. 

Description: Soap delivery 
Delivered at: 2011-01-03 

Invoice Reference Number: 0000000000000126X 

Delete Invoice 
Edit | Back 


On second thought, using concat was an ugly approach. Change the display_invoice call to an 
expression (i.e. change" <% display_invoice . . . at show . html . erb to <%= display_invoice . . .) and 


9, https://github.com/bryanbibat/rasm40code/commit/14dae7a27f7048f41c826c459ca879bl0d04e0e4#diff-3 
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change the helper to the following 100 : 

module PurchasesHelper 

def display_invoice(purchase) 
unless purchase. invoice nil? 

render 'invoice', purchase: @purchase 
else 

render ' no_invoice ' , purchase: ©purchase 
end 
end 
end 

Then create the following partials: 

# app/views/purchases/_no_invoice . html . erb 101 

<p> 

<%= link_to "Create Invoice", new_purchase_invoice_path(@purchase) %> 

</p> 

# app/views/purchases/_invoice . html . erb 102 

<p> 

<b>Invoice Reference Number: </b> 

<%= link_to @purchase. invoice. reference_number, 
ed i t_purchase_i nvoi ce_path ( ©purchase ) %> 

</p> 

<p> 

<%= link_to "Delete Invoice", purchase_invoice_path(©purchase) , 
data: { confirm: "Are you sure?" }, method: : delete %> 

</p> 

One-to-Many Relationships 

Once you know how to create a one-to-one relationship, one-to-many associations should be simple. Let’s 
create a Supplier-Purchase one-to-many association, that is, Aling Nena could make multiple purchases 
from a single supplier. 

Here’s the script for the basic setup: 

$ rails generate scaffold supplier name: string contact_number : string 
$ rails generate migration AddSuppl ierToPurchase suppl ier_id : integer 
$ rake db: migrate 

Note that we didn’t use : references in the migration because it doesn’t work with add_column. 

Modify the models like so: 

# app/models/purchase . rb 103 

100 littps://github.com/bryanbibat/rasm40code/commit/14dae7a27f7048f41c826c459ca879bl0d04e0e4#diff-0 

101 https://github.com/bryanbibat/rasm40code/commit/14dae7a27f7048f41c826c459ca879bl0d04e0e4#diff-2 

102 https://github.com/bryanbibat/rasm40code/commit/14dae7a27f7048f41c826c459ca879bl0d04e0e4#diff-l 

103 https://github.com/bryanbibat/rasm40code/commit/63df7100249a43676b0076d791ead9672c9aa6el#diff-5 
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class Purchase < Act i veRecord :: Base 
has_one : invoice 

belongs_to : supplier 

def display_suppl ier 

return supplier . name unless supplier . nil? 
end 

end 

# app/models/suppl ier . rb 104 

class Supplier < Act i veRecord :: Base 

has_many : purchases 
end 

The argument : purchases should be plural according to convention. 

As for the purchase screen 105 , collection_select is appropriate for the Supplier-Purchase association: 


<%= f . date_select : del ivered_at %> 

</div> 

<div class="field"> 

<%= f. label :supplier_id, "Supplier" X><br> 

<%= f .collection_select :supplier_id, Supplier. all, :id, :name, prompt: true %> 
</div> 

<div class="actions" > 

<%= f. submit %> 

</div> 


We also need to modify our Purchases controller 106 to allow this new field: 


def purchase_params 

params require( : purchase) permit( description, : del ivered_at, : suppl ier_id) 
end 


If you want to modify the Show Purchase screen to show the Supplier, just use the display_supplier 107 
method from the model. 

Before we can proceed with displaying the list of Purchases under the Supplier, we must first understand 
what the has_many declaration does to a model. 

104 https://github.com/bryanbibat/rasm40code/commit/63df7100249a43676b0076d791ead9672c9aa6el#diff-6 

105 https://github.com/bryanbibat/rasm40code/commit/63df7100249a43676b0076d791ead9672c9aa6el#diff-7 

106 https://github.com/bryanbibat/rasm40code/commit/63df7100249a43676b0076d791ead9672c9aa6el#diff-2 

107 https://github.com/bryanbibat/rasm40code/commit/3fSd0c83478e4bfc8704a81b0c8c96c402ff5c49#diff-0 
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hasjnany 

The following instance methods are added to Supplier after we added the hasjnany : purchases in the 
model class: 

• suppl ier . purchases - returns a list of Purchase objects associated with the Supplier. This is also 
cached so if you want to reload the list, just passtrue to the method. 

• suppl ier . purchases < < new_purchase - adds a Purchase to the list of Purchases associated with 
the Supplier. 

• supplier . delete (*purchase) - removes the association to the object or objects specified. When 
an association is removed, the action done to the object depends on the : dependent option i.e. it 
will either nullify the field or delete the record. 

• suppl ier . purchases = 1 ist_of_purchases - assigns a list of Purchase objects to the Supplier, 
removing associations as appropriate. 

• suppl ier . purchase_ids, suppl ier . purchase_ids = 1 ist_of_purchase_ids -just like .purchases, 
but instead of dealing with a list of Purchase objects, this just uses a list of ids of those objects. 

• supplier .purchases, clear - removes all associations to Purchase objects. 

• suppl ier . purchases . empty? - returns true if there are no associated Purchases 

• supplier .purchases, size - returns the number of associated Purchases 

• suppl ier . purchases . f ind( ), suppl ier . purchases . exist?( ) - basically just Acti veRecord . find 
and Acti veRecord .exist? but only uses the Purchase records associated with the Supplier 

• suppl ier . purchases . bui ld( ), suppl ier . purchases . create( ) - just like the build_xxxx and 
create_xxxx from has_one 

With this knowledge, we can now add the list of Purchases in the Show Supplier screen 108 : 

<hl>Supplier Details</hl> 

<p> 

<strong>Name : </strong> 

<%= ©supplier name %> 

</p> 

<p> 

<strong>Contact number : </strong> 

<%= ©suppl ier . contact jiumber %> 

</p> 

<h2>Related Purchases</h2> 

<ul> 

<% ©supplier purchases each do | purchase I %> 

<li> <%= link_to purchase description, purchase 

<% end %> 

</ul> 


108 https://github.com/bryanbibat/rasm40code/commit/3fSd0c83478e4bfc8704a81b0c8c96c402ff5c49#diff-l 
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The resulting page is: 


x - n 


1 AlingnenaApp 


^ C © localhost:3000/suppliers/1 & A 1 

Supplier Details 

Name: Cola Factory 

Contact number: 000-0000 

Related Purchases 

• Cola delivery 

• Another Cola delivery 

Edit | Back 



Many-to-many Relationships 

We can use Purchase and Product to demonstrate how many-to-many associations are done in Rails. A 
Purchase can consist of many Products, while a Product can be part of many Purchases. There are two 
ways declaring this many-to-many relationship in Rails, and both require a join table. 

has_and_belongs_to_many 

We can declare has_and_belongs_to_many in our models to specify that the models have a many-to-many 
relationship with each other. For this to work, there must first be an existing join table that satisfies the 
following conditions: 

• It must be named according to the tables involved in the relationship, separated by underscore and 
arranged alphabetically. In the Product-Purchase case, the table should be products_purchases. 

• It must only contain references to each table. It should not have any other fields e.g. primary key. 

Let’s setup the product_purchase table with a migration: 

$ rails generate migration CreateProductsPurchases 


Edit the generated migration: 
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class CreateProductsPurchases < ActiveRecord :: Migration 

def change 

create_table : products_purchases, id: false do I t I 
t. integer :product_id 
t. integer :purchase_id 

end 

end 

end 

The id : false option removes the default primary key field from the table. 
Then add the has_and_belongs_to_many declaration in the model 109 : 

* app/model s/product . rb 

class Product < ActiveRecord :: Base 
validates :name, presence: true 
validates description, presence: true 
has_and_belongs_to_many : purchases 


* app/model s/purchase . rb 

class Purchase < ActiveRecord :: Base 
has_one : invoice 
belongs_to : supplier 

has_and_belongs_to_many : products 


At this point, you can already perform has_many methods on both sides. For example: 
some_product . purchases << new_purchase 

some_product . purchases # this will return a list containing new _purchase 

new_purchase . products # this will return a list containing some_product 

The has_and_belongs_to_many declaration is suited for simple many-to-many relationships. One possible 
scenario is a Book-liking module where Users can “like” Books. In turn, a Book can have many Users that 
“like” it. 

For more complex relationships that would have other details, we would need another approach. For 
example, the relationship between Purchase and Product may also require us to specify the quantity of 
the Product in that Purchase. We can’t store that in our join table because of the limitations of that table. 

The has_many : through declaration provides the other approach to many-to-many relationships. 

More on One-to-Many 

The has_many : through declaration works because it uses two one-to-many associations linked together 
by one join table: 


109 https://github.com/bryanbibat/rasm40code/commit/24ed73768be0a4b75701ld5a663e65a233552dc5 
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Product 


Line Item 


Purchase 


productjd 

purchasejd 


V 

y 


Once declared, this association works just like has_and_belongs_to_many wherein you could call methods 
like some_product . purchases. It’s not that complicated, so let’s take this time to explore one-to-many 
again instead. 

Our join table for Product- Purchase would be Line Items, child records of Purchase that would represent 
lines in the Invoice. This is where Aling Nena would input the quantity, cost, and (most importantly) the 
Product involved. 

Setting up the Line Items program should be easy with rails generate scaffold: 

$ rails generate scaffold line_item purchase : references product : references \ 
quantity : integer cost: decimal 

Taking a cue from Invoice, we’ll make Line Item a child resource for Purchase to make maintenance easier. 

Nested Resources 

We’ve previously discussed what routes are generated when a singular resource is assigned as a child to 
a resource route. Now we’ll assign a normal resource under a resource route 110 : 

A1 ingnenaApp : : Appl ication routes draw do 
resources : suppliers 

resources : purchases do 
resource : invoice 

resources :line_items 
end 

resources : debts 
resources : products do 
collection do 
get 'search' 

end 

end 

end 

This generates the following routes: 


110 https://github.com/bryanbibat/rasm40code/commit/42f56f4db48bc449b37274be2ea229d31dbe5dlb#diff-15 
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helper 

HTTP verb 

URL 

controller 

action 

purchase_l ine_item_url 

GET 

/purchases/ : purchase_- 

Lineltems 

index 

purchase_l ine_item_path 
new _purchase_l i ne_i tem_ur 1 

GET 

id/1 ine_i terns 
/purchases/ : purchase_- 

Lineltems 

new 

new _purchase_l ine_item_path 

POST 

id/1 ine_items/new 
/purchases/ : purchase_- 

Lineltems 

create 


GET 

id/1 ine_i terns 
/purchases/ : purchase_- 

Lineltems 

show 

edit_purchase_l ine_item_ur 1 

GET 

id/1 ine_i terns/ : id 
/purchases/ : purchase_- 

Lineltems 

edit 

edit_purchase_l ine_item_path 

PUT / PATCH 

id/1 ine_i terns/ : id/edit 
/purchases/ : purchase_- 

Lineltems 

update 


DELETE 

id/1 ine_i terns/ : id 
/purchases/ : purchase_- 

Lineltems 

destroy 


id/1 ine_i terns/ : id 

With routes set, we proceed with some model changes: 

# app/models/purchase . rb 111 

class Purchase < ActiveRecord : : Base 
has_one : invoice 
belongs_to : supplier 

has_many :line_items 


# app/models/product . rb 112 

class Product < ActiveRecord :: Base 

validates : description, presence: true 
has_many :line_items 


After the model comes the controller rewrite ofapp/controller/line_items_controller.rb 113 : 


class LineltemsController < Appl icationControl ler 

before_action : set_l ine_item, only: [:edit, :update, :destroy] 

def index 

# integrate with show purchase 

redirect_to Purchase. find(params[ : purchase_id] ) 

end 


def show 

# integrate with show purchase 

redirect_to Purchase . f ind(params [ : purchase_id] ) 

end 


111 https://github.com/bryanbibat/rasm40code/commit/42f56f4db48bc449b37274be2ea229d31dbe5dlb#diff-6 

112 https://github.com/bryanbibat/rasm40code/commit/42f56f4db48bc449b37274be2ea229d31dbe5dlb#diff-5 

113 https://github.com/bryanbibat/rasm40code/commit/42f56f4db48bc449b37274be2ea229d31dbe5dlb#diff-2 
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def new 

©purchase = Purchase. find(params[ :purchase_id] ) 

@line_item = ©purchase . 1 ine_i terns . bui Id 

end 

def edit 

end 

def create 

©purchase = Purchase. find(params[ : purchase_id] ) 

@line_item = ©purchase . 1 ine_i terns . bui ld( 1 ine_item_params) 
if @1 ine_i tem . save 

redirect_to ©purchase, notice: 'Line Item was successfully created.' 

else 

render action: "new" 

end 

end 

def update 

if ©1 ine_item . update_attributes( 1 ine_item_params) 

redirect_to ©purchase, notice: 'Line Item was successfully updated.' 

else 

render action: "edit" 

end 

end 

def destroy 

@1 ine_item . destroy 

redirect_to ©purchase, notice: 'Line Item was successfully deleted.' 

end 

private 

* Use callbacks to share common setup or constraints between actions. 
def set_l ine_item 

©purchase = Purchase. find(params[ :purchase_id] ) 

©line_item = ©purchase . 1 ine_i terns . find(params [: id] ) 

end 

# Never trust parameters from the scary internet, only allow the white list through. 
def 1 ine_item_params 

params require( : 1 ine_item) . permit( : product_id, : quantity, : cost) 

end 

end 

And the views (null handling not implemented): 

# app/views/purchases/show . html . erb 114 


114 https://github.com/bryanbibat/rasm40code/commit/42f56f4db48bc449b37274be2ea229d31dbe5dlb#diff-14 
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<%= display_invoice @purchase %> 

<h2>Line Items</h2> 

<table> 

<thead> 

<tr> 

< th > Product </th> 

< th> Quant ity</th> 

<th>Cost</th> 

</tr> 

</thead> 

<tbody> 

<% §purchase . 1 ine_i terns . each do |item| %> 

<tr> 

<td><^= item . product name %></td> 

<td><^= item . quantity ^></td> 

<td><%= number_to_currency item. cost, unit: "PhP" %></td> 

<td><%= link_to "Edit", edit_purchase_l ine_item_path(§purchase, item) %></td> 
<td> 

<%= link_to "Destroy", purchase_line_item_path(@purchase, item), 
data: { confirm: "Are you sure?" }, method: : delete %> 

</td> 

</tr> 

<Z end 
</tbody> 

</table> 

<p > <%= link_to "New Line Item", new_purchase_l ine_item_path(§purchase) Z></p> 

<%- link_to 'Edit', edit_purchase_path(@purchase) %> \ 


# app/views/1 ine_items/new . html . erb 115 
<hl>New Line Item</hl> 

<%= render 'form', purchase: §purchase, line_item: @line_item %> 

# app/views/1 ine_items/edit . html . erb 116 
<hl>Editing Line Item</hl> 

<%= render 'form', purchase: §purchase, line_item: §line_item %> 

# app/views/1 ine_items/_form . html . erb 117 

115 https://github.com/bryanbibat/rasm40code/commit/42f56f4db48bc449b37274be2ea229d31dbe5dlb#diff-ll 

116 https://github.com/bryanbibat/rasm40code/commit/42f56f4db48bc449b37274be2ea229d31dbe5dlb#diff-8 

117 https://github.com/bryanbibat/rasm40code/commit/42f56f4db48bc449b37274be2ea229d31dbe5dlb#diff-7 
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<%= form_for( [purchase, line_item]) do |f| %> 

<% if 1 ine_item . errors . any? %> 

<div id="error_explanation" > 

<h2><%= plural ize( 1 ine_item . errors . count , "error") %> prohibited this Line Item 
from being saved :</h2> 

<ul> 

<% 1 ine_i tern . errors . ful l_messages . each do Imsgl %> 

<li><%= msg %></li> 

<% end 
</ul> 

</di v> 

<% end %> 


<div class=" field" > 

< label > Purchase < /label > <br> 
purchase . description %> 

</div> 

<div class=" field" > 

<%= f label :product_id, "Product" ^><br> 

<%= f . col lection_select :product_id, Product. all, :id, :name, prompt: true %> 
</div> 

<div class=" field" > 

<Z= f label :quantity %><br> 

<%= f.text_field : quantity %> 

</div> 

<div class=" field" > 

<%~ f label :cost ^><br> 

<%= f.text_field : cost %> 

</div> 

<div class="actions" > 

<%- f. submit %> 

</div> 

<% end %> 


<%= link_to 'Back', purchase %> 


Here’s the program in action: 
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: — n 


’ AlingnenaApp 

^ 


4* C © localhost:3000/purchases/1 & ^ 


Description: Cola delivery 
Delivered at: 2011-01-02 

Invoice Reference Number: 0000000000000128X 
Delete Invoice 

Line Items 

Product Quantity Cost 

Cola 10 PhP250.00 Edit Destroy 

New Line Item 
Edit | Back 


11 

— n 

i 



r c 

O localhost:3000/purchases/1/line_items/new & 



New Line Item 


Purchase 
Cola delivery 

Product 
Please select 


Quantity 


Cost 


Create 


Back 
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c — n 


| AlingnenaApp 

^ 


Q localhost:3000/purchases/1 & \ 


Line Item was successfully created. 

Description: Cola delivery 
Delivered at: 2011-01-02 

Invoice Reference Number: 0000000000000128X 
Delete Invoice 

Line Items 

Product Quantity Cost 

Cola 10 PhP250.00 Edit Destroy 

Lemon Lime Soda 20 PhP500.00 Edit Destroy 

New Line Item 

Edit | Back 


Nothing really new here. Sharp eyed readers might notice the strange usage of form_for in Invoice and 
Line Items. In Invoice, the form_for is written as: 


<% form_for( invoice, :url => purchase_invoice_path(purchase) ) do If I %> 


The :url option overrides the expected URL helper, invoice_path(purchase), with purchase_invoice_- 
path ( purchase ) . Since this is a singleton resource, both create and update URLs are the same so the partial 
works for both cases. 

In Line Items, the form_for is written as: 

<% form_for( [purchase, line_item]) do |f| %> 

Instead of a single object, we pass an array of objects. Based on this array of objects, Rails knows what 
URL to use according to the convention. If the line_item object was new, the path it will use will be 
purchase_line_items_path(purchase). If it’s already existing, the path will be purchase_l ine_item_- 
path(purchase, line_item). 

hasjmany :through 

Now that we could create Line Items, it’s time to show how we can use the many-to-many relationship 
in the Products side. For this, we need to add the has_many : through declaration 118 : 


118 https://github.com/bryanbibat/rasm40code/commit/4e7e500de73849ec5cf2aced54f5783981c3f9ld#diff-0 
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validates : description, presence: true 
has_many :line_i terns 

has_many : purchases, through: :line_items 


The : through specifies the join table used for the relationship. This join table must also be declared as the 
target table in a has_many declaration. 

We can now access the list of Purchases involving the Product through product . purchases. Here’s one 
way of doing it at app/views/products/show . html . erb 119 : 


<p> 

<strong> Stock : </strong> 

<%= @product . stock %> 

</p> 

<h2>Related Purchases</h2> 

<ul> 

<% @product . purchases each do I purchase I %> 

<li><%= link_to purchase description, purchase 

<% end %> 

</ul> 


<%= link_to 'Edit this record 1 , edit_product_path((g>product) %> <br /> 


And the result: 




- n 


AlingnenaApp 

X ^ 


C © localhost:3000/products/3 ^ 


Show Product 

Name: Cola 
Description: fizzy drink 
Cost: PhPlO.OO 
Stock: 10 

Related Purchases 

• Cola delivery 

• Another Cola delivery 

Edit this record 
Delete this record 
Back to List of Products 


119 https://github.com/bryanbibat/rasm40code/commit/4e7e500de73849ec5cf2aced54f5783981c3f91d#diff-2 


Associations 


120 


Just to show that the many-to-many goes both ways, let’s do the same for Purchase (even though it will 
look redundant): 

# app/models/purchase . rb 120 

class Purchase < Act i veRecord :: Base 
has_one : invoice 
belongs_to : supplier 
has_many :line_i terns 

has_many : products, through: :line_i terns 

def display_suppl ier 

return suppl ier . name unless suppl ier . ni 1 ? 
end 
end 


# app/views/purchases/show . html . erb 121 


<p><^= link_to "New Line Item", new_purchase_l ine_item_path(§purchase) Z></p> 

<h2>Related Products</h2> 

<ul> 

<% @purchase products each do I product I %> 

<li> <%= link_to product . name, product ^></li> 

<% end %> 

</ul> 


<%= link_to 'Edit 1 , edit_purchase_path(§purchase) %> I 


Here’s the updated page: 


12 °https://github.com/bryanbibat/rasm40code/commit/4e7e500de73849ec5cf2aced54f5783981c3f91d#diff-l 

m https://github.com/bryanbibat/rasm40code/commit/4e7e500de73849ec5cf2aced54f5783981c3f91d#diff-3 
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: — n 


AlingnenaApp 

^ 


Q © localhost:3000/purchases/1 & A 


Description: Cola delivery 
Delivered at: 2011-01-02 

Invoice Reference Number: 0000000000000128X 
Delete Invoice 

Line Items 

Product Quantity Cost 

Cola 10 PhP250.00 Edit Destroy 

Lemon Lime Soda 20 PhP500.00 Edit Destroy 

New Line Item 


Related Products 

• Cola 

• Lemon Lime Soda 
Edit | Back 


The whole thing looks ok, but what if you add another “Cola” Line Item to 


“Cola delivery”? 




_ n 

■ ■ 1 

AlingnenaApp 




C © localhost:3000/products/3 ^ 


Show Product 

Name: Cola 
Description: fizzy drink 
Cost: PhPlO.OO 
Stock: 10 

Related Purchases 

• Cola delivery 

• Another Cola delivery 

• Cola delivery 

Edit this record 
Delete this record 
Back to List of Products 


Cola delivery is listed twice since there are two references to Cola in Line Items. To eliminate the redundant 
results, we can add the uniq scope: 

# app/models/purchase . rb 122 


122 https://github.com/bryanbibat/rasm40code/commit/e5f25799e9929537eb803fe5cld74e55559483f3#diff-l 
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class Purchase < Act i veRecord :: Base 
has_one : invoice 
belongs_to : supplier 
has_many :line_i terns 

— has_many — : products, — through : — : 1 inc_itcms 

has_many : products, -> { uniq }, through: :line_i terns 

def display_suppl ier 

return suppl ier . name unless suppl ier . ni 1 ? 
end 
end 

# app/models/product . rb 123 


class Product < ActiveRecord : : Base 
validates :name, presence: true 
validates : description, presence: true 
has_many :line_i terns 

— has_many — : purchas e s, — through : — : 1 in o _it c ms 

has_many purchases, -> { uniq }, through: :line_i terns 

def before_val idation 
if description . blank? 
self description = name 

end 

end 

end 

Trying the two pages produces: 


123 https://github.com/bryanbibat/rasm40code/commit/e5f25799e9929537eb803fe5cld74e55559483f3#diff-0 
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- n 


sn - rm 

' AlingnenaApp 


1 [j AlingnenaApp 


C © localhost:3000/products/3 fa ^ 


Show Product 

Name: Cola 
Description: fizzy drink 
Cost: PhPlO.OO 
Stock: 10 

Related Purchases 

• Cola delivery 

• Another Cola delivery 

Edit this record 
Delete this record 
Back to List of Products 



# 


C © localhost:3000/purchases/1 fa ^ 


Description: Cola delivery 
Delivered at: 2011-01-02 

Invoice Reference Number: 0000000000000128X 
Delete Invoice 

Line Items 

Product Quantity Cost 

Cola 10 PhP250.00 Edit Destroy 

Lemon Lime Soda 20 PhP500.00 Edit Destroy 

Cola 10 PhP250.00 Edit Destroy 

New Line Item 

Related Products 

• Cola 

• Lemon Lime Soda 
Edit | Back 


Another problem is the amount of queries are performed in our Purchase page: 


Processing by PurchasesController#show as HTML 
Parameters: {"id"=>"l"} 

Purchase Load (0.2ms) SELECT "purchases".* FROM "purchases" WHERE "purchases" . "id" = 1 LIMIT 1 
Invoice Load (6.3ms) SELECT "invoices".* FROM "invoices" WHERE ("invoices" .purchaseid = 1) LIMIT 1 
Lineltem Load (6.3ms) SELECT "line_items".* FROM "line_items" WHERE ("line_items".purchase_id = 1) 
Product Load (6.2ms) SELECT "products".* FROM "products" WHERE "products" . "id" = 3 LIMIT 1 
Product Load (6.8ms) SELECT "products".* FROM "products" WHERE "products" . "id" = 4 LIMIT 1 
CACHE (6.6ms) SELECT "products".* FROM "products" WHERE "products" . "id" = 3 LIMIT 1 
Product Load (1.3ms) SELECT DISTINCT "products".* FROM "products" INNER JOIN "line_items" ON "produc 
ts".id = "line_items".product_id WHERE (("line_items".purchase_id = 1)) 

Rendered purchases/show. html.erb within layouts/application (147.3ms) 


A query is made for every Product record that needs to be displayed in the page. To reduce this to fewer 
queries, we can chain the includes( ) method after the find method for show 124 : 


def set_purchase 

@purchase = Purchase includes(line_items: : product) . find(params [: id] ) 


This will tell Rails to “eager-load” the line items association (and its child association, product) as opposed 
to the default “lazy-load” approach where the records are retrieved only when needed (e.g. a product . name 

call). 


124 https://github.com/bryanbibat/rasm40code/commit/dcaf07d43de79e00ee59dd770e395121acd0ae39 




Associations 


124 


Processing by PurchasesController#show as HTML 
Parameters: {"id“=>"l"} 

Purchase Load (6.3ms) SELECT "purchases".* FROM "purchases" WHERE "purchases" . "id" = 1 LIMIT 1 
Lineltem Load (6.3ms) SELECT "line_items".* FROM "line_items" WHERE ("line_items" .purchase_id = 1) 
Product Load (6.6ms) SELECT "products".* FROM "products" WHERE ("products". "id" IN (3,4)) 

Invoice Load (6.2ms) SELECT "invoices".* FROM "invoices" WHERE ("invoices" .purchase_id = 1) LIMIT 1 
Product Load (6.9ms) SELECT DISTINCT "products".* FROM "products" INNER JOIN "lineitems" ON “produc 
ts".id = "line items". productid WHERE ((“line items". purchase id = 1)) 


The action is now reduced to 5 queries from its original 7. 

The includes( ) call isn’t limited to a single relationship hierarchy. You can pass arrays and hashes in the 
includes( ) call to eager-load any relationship you want. For example, the following is not practical, but 
will not throw an error: 


©purchase = Purchase . includes( [: invoice, { 1 ine_i terns : [: product, : purchase]}, 

: supplier] ) 

. f ind(params [ : id] ) 


As you might have guessed, arrays denotes the “sibling” relationship under a current model (e.g. : invoice, 
: line_item, and : supplier are all under the Purchase model) while a hash would denote moving to a 
different model (e.g. : product and : purchase are under the Lineltem model). 




Skimming through Rails 

Rails is a simple but fairly large framework. We can’t cover everything in this course, so in this chapter, 
we will go through the features that you might have to use on a regular basis. 

Rails Migrations 

We’ve discussed the basics of migrations, namely, how to create or drop a table and how to add or remove 
columns from them. We also used generator scripts for the migrations instead of coding them manually. 

In this part, we’ll discuss the various methods available to us in the migrations. We’ll also go deeper in 
the mechanisms behind migrations. 

Creating Tables 

The create_table method accepts a table name and a block where we define the fields in the table. Going 
back to our first migration: 

def change 

create_table : debts do | t I 
t. string :name 
t . text : item 
t. decimal : amount 

t . timestamps 
end 
end 

This create_table call creates the table debts in the database with an integer primary key “id”, a string 
field “name”, a text field “item”, a decimal field “amount”, and two timestamp fields “created_at” and 
“updated_at”. 

We’ve discussed before the possible data types for use in defining columns. Here’s the fields that would 
be created per database for those data types: 
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db2 

mysql 

openbase 

oracle 

postgresql 

sqlite 

sqlserver 

Sybase 

: binary 

blob(32768) 

blob 

object 

blob 

bytea 

blob 

image 

image 

: boolean 

decimal(l) 

tinyint(l) 

boolean 

number(l) 

boolean 

boolean 

bit 

bit 

:date 

date 

date 

date 

date 

date 

date 

datetime 

datetime 

: datetime 

timestamp 

datetime 

datetime 

date 

timestamp 

datetime 

datetime 

datetime 

: decimal 

decimal 

decimal 

decimal 

decimal 

decimal 

decimal 

decimal 

decimal 

: float 

float 

float 

float 


float 

float 

float(8) 

float(8) 

: integer 

int 

int(ll) 

integer 

number(38) 

integer 

integer 

int 

int 

: string 

varchar(255) 

varchar(255) 

varchar(4096) 

varchar2(255) 

character 

varying(256) 

varchar(255) 

varchar(255) 

varchar(255) 

: text 

dob(32768) 

text 

text 

clob 

text 

text 

text 

text 

: time 

time 

time 

time 

date 

time 

datetime 

datetime 

time 

: timestamp 

timestamp 

datetime 

timestamp 

date 

timestamp 

datetime 

datetime 

timestamp 


There are also shorthand data types e.g. the t . references from the previous lesson. 

There are options you could specify to each column declaration to apply database-level constraints: 

• : nul 1 - set this option to true if nulls are allowed for this field, false otherwise 

t. string :name, :null => false # sets name field to mandatory 

• : default - set this option to make the database set a default value for the field if the field is left 
empty. If you want the field default to be NULL, use nil. 

• : 1 imit - set this option to the maximum size of the field This refers to the number of characters 
for : string and :text, number of bytes for the : binary and : integer. 

The following options are for : decimal: 

• : precision - the precision of the decimal column, the number of significant digits in the number 

• : scale - the scale of the decimal column, the number of digits after the decimal point. The number 
123.45 has a precision of 5 and a scale of 2. 

Note that these column options can also be used in the add_column method. For example: 

add_column :debts, :remarks, :text, : limit => 200 

You can also set options for the table by passing a hash of options after the table name: 

• id => false - this will prevent the automatic creation of the primary key 

• : pr imary_key - if : id is is not set to false, you can set this option to change the name of the primary 
key from “id” e.g. 

create_table : debts, primary_key: "debt_no" do I t I 

• : force => true - this will make the migration drop the table of the same name (if it exists) before 
creating the table 

• : temporary => true - the table created is only temporary and will be dropped when the connection 
is closed. 

• : options - the value specified in this option will be appended to the table definition SQL. For 
example: 
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create_table :debts, :options => "ENGINE=InnoDB DEFAULT CHARSET=utf8" do |t| 
will create 

CREATE TABLE debts ( 

) ENGINE=InnoDB DEFAULT CHARSET=utf8 

Other Migration Methods 

Here are some other methods you can use in the migrations: 

• change_column(table_name, column_name, type, options = {}) - changes a column to the 
specified type and options. The column options are the same from create_table and add_column. 
For example, you want to change the maximum length of remarks, you could use: 

change_column : debts, : remarks, :text, limit: 300 

• rename_column(table_name, column_name, new_column_name) - renames a column to new_- 
column_name 

• add_index(table_name, column_name, options = {})- adds an index to the table. You can set 
the name of the index as well as the unique setting in the options. 

• remove_index(table_name, options = {})- removes an index from the table 

• rename_table(table_name, new_name) - renames tabletable name tonew name 

• change_table(table_name) - changes columns in thecreate_table syntax. 

Migration Mechanism 

When you run rake db : migrate, Rails first checks theschema_migrations table for the list of migrations 
already applied to the database then it applies all migrations not already inside the table. For example, we 
have the following situation: 


20100601120000_....rb 
20100601110000_....rb 
20 100601100000_. . . . rb 
20100601090000_....rb 
20100601080000 ....rb 


A 




/db/migrate 


schema_migrations 


2010060 1110000_. . . . rb 
20100601100000_....rb 
20100601080000 ....rb 


In this case, our schema_migrations table is missing the 12 noon and 9AM migrations. The missing 9AM 
migration is possible, you might have just updated your local version of the application and got that 
migration from another developer. Running rake db: migrate will apply the two migrations into your 
database and insert two new records to the schema_migrations table. 

To rollback your database to an older version, you can use the VERSION environment variable to pass a 
timestamp: 
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$ rake db: migrate VERSION=2010060113000 

This will rollback all migrations after the specified timestamp (if any; it’s possible to use this call for a 
“roll-forward”) and apply all migrations on or before the said timestamp. 

Active Record 

There are still a lot of important concepts in Active Record that we haven’t discussed in detail yet. 

Querying 

Aside from f ind( ) and al 1 ( ), there are two other general methods for retrieving records: 

• f irst( ) - returns the first record retrieved from the table. 

• last( ) - returns the last record retrieved from the table.. 

As we’ve seen in the includes( ) method in the previous lesson, these methods can be chained with other 
methods to modify their behavior. Note that al 1 ( ) is used by default so you don’t need to specify it in a 
chain with other methods. 

Below are the methods that you can use for querying. 

where 

You can define the WHERE part of the SQL statement with thewhere method. It accepts either a string, 
an array that starts with a string, or a hash. Passing a string would simply make it use the string as the 
SQL WHERE clause of the query. For example: 

User where( "user_name = ' *{user_name} ' AND password = ' ^{password} '"). first 

would find the record with a user name and password that matches the supplied credentials. Obviously 
this approach is prone to SQL injection attacks, so a better approach would be to use an array argument 
which creates a parameterized WHERE clause. 

User where( "user_name = ? AND password = ?", user_name, password) . first 

The 2nd element onwards are assigned to the question marks after sanitizing the elements. The problem 
with this form of parameterized queries is that when the query becomes larger, it becomes difficult to 
determine which parameter is assigned to which question mark. Here we can use named parameters 
(symbols inside the string) and a hash for the second element: 

User where( "user_name = : user_name AND password = : password", 

{ : user_name => user_name, : password => password }). first 

For simple queries like the one above, you can use a hash of values. Rails would automatically convert the 
key-value pairs into a series of ‘key = value’ entries in theWHERE clause, also sanitizing the input in the 
process. 
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User.where( : user_name => user_name, : password => password ). first 


order, select, from 

The order ( ) method allows you to provide the contents of the ORDER BY clause in the query. For example: 
L ine I tern . order ( "purchase_id DESC, id") 

The select( ) method allows you to define the fields for SELECT clause. By default, ActiveRecord uses 
“*” to select all fields in the table but if your database incurs a performance hit when you query certain 
fields (e.g. BLOB fields), you might want to remove those fields from the SELECT clause. As the object’s 
attributes are dynamically assigned, the removed fields will not be available in the return objects. 

>> d Debt . select( " id" ). first 
=> #<Debt id: 1> 

> > d . name 

ActiveRecord MissingAttr ibuteError missing attribute: name 

Similar to select( ) and order ( ), from( ) allows you to specify the fragment for the FROM clause. You 
might want to do this if you’re using a different table or a view for the query. 

:group, :having. Calculations 

The group( ) and having( ) methods are also like order( ), they allow you to provide the SQL fragments 
for GROUP BY and HAVING clauses in the query, respectively. 

Lineltem . group( "product_id" ) 

Lineltem . group( "purchase_id" ) . having( "purchase_id = 1") 

Since HAVING only applies to GROUP BY, : having will only be applied to the query if there is a : group 
option specified. 

Queries involving group ( ) will only return one record per “group”. Because of this, group ( ) and having( ) 
are better used with the aggregate functions under ActiveRecord : : Calculations. The available functions 
are: 


• count - returns the number of records per group 

Lineltem . group ( "purchase_id" ) . count 

• average - returns the average value of a specified field per group 

Lineltem . group( "purchase_id" ) . average( "cost" ) 

• sumLine - returns the sum of the values of a specified field per group 

Item . group( "purchase_id" ) . sum( "cost" ) 

• maximum, minimum - returns the maximum and minimum value of a specified field per group 
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Lineltem . group( "purchase_id" ) maximum( "cost" ) 

Lineltem . group( "purchase_id" ) minimum( "cost" ) 

The return value for these methods will be a hash of the “field name used ingroup” => “calculated value”. 
Note that these aggregate functions only work for one grouping field name, using more than one (e.g. 
group ( "purchase_id, product_id" )) would return unpredictable results. 

Also note that the aggregate functions can be used without the group ( ) method to calculate the value for 
the entire table (the result will be a single value, not a hash). 

:limit, :offset 

The : 1 imit option allow you to specify how many records are retrieved by the query. 

Debt . 1 imit(10) 

When the : limit option is used for paginating records, we often employ another option, : offset, to 
determine the “starting point” for the query. The number passed to : offset determines the number of 
records to skip in the query. For example: 


Debt . of fset(5) 

This query skips the first 5 records retrieved and starts with the 6th record. 

:readonly, Mock 

Set readonly to true if you want to prevent updates to the retrieved records. 

>> d = Debt . readonly(true) . first 
=> #<Debt id: i , name: ...> 

>> d.save 

ActiveRecord : : ReadOnlyRecord : ActiveRecord : : ReadOnlyRecord 


You can use lock( ) to add a fragment for locking in the query e.g. “FOR UPDATE” or “LOCK IN SHARE MODE”. 
Using lock(true) uses the default exclusive lock for the connection, usually “FOR UPDATE”. 

find_by_sql 

When all else fails, you can always specify an SQL query via the f ind_by_sql method. The attributes of 
the objects are dynamically assigned from the results of the query. 
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>> line_items = Lineltem . find_by_sql ( "SELECT pu . description purchase_description, 
pr.name, product_name FROM line_i terns li, purchases pu, products pr WHERE 
1 i . purchase_id = pu.id AND 1 i . product_id = pr.id") 

=> [#<LineItem >, #<LineItem >, ...] 

>> 1 ine_i terns [0] . purchase_description 
=> "Cola delivery" 

>> 1 ine_i terns [0] . product_name 
=> "Cola" 

Scopes 

ActiveRecord allows you to convert commonly used queries into scopes. Let’s use some trivial examples: 

class Debt < ActiveRecord :: Base 

scope :new_first, -> { order( "created_at DESC")} 

scope : has_debt_greater_than, -> (x) { where( "amount > ?", x).limit(5) } 

end 

The scope definition accepts a symbol to define the scope name and a Proc with ActiveRecord query calls. 
You can call them directly: 

Debt new_first 

Debt has_debt_greater_than(20) 

You can also merge them: 

Debt has_debt_greater_than(20) ,new_first 

You can also set a default scope which is called every time a query is made to the model: 

class Debt < ActiveRecord :: Base 

scope :new_first, -> { order( "created_at DESC")} 

scope : has_debt_greater_than, -> (x) { where( "amount > ?", x).limit(5) } 
default_scope { new_first } 

end 

Here we also see chained scopes, with new_f irst being called inside the default scope. 

If you want to skip the default scope, you can use the unscoped method: 


Debt unscoped . load 
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Validation 

There are other validations aside from validates ... : presence listed in the API docs under 

ActiveRecord : : Validations : : ClassMethods. Here’s a list of the methods listed there: 

• : acceptance - validates if the specified field is accepted by the user, usually used in terms of service 
check boxes. 

• validates_associated - validates if the objects in the specified associations are valid. 

• : confirmation - validates if a copy of the specified field (appended with a confirmation, e.g. 
emai 1 confirmation for email) is part of the submitted form and matches the specified field. This 
confirmation field is not saved along with the record though it can be accessed like any other field 
i.e. it’s a virtual field. 

• validates_each - validates each attribute against a block 

• inclusion , : exclusion - validates if the value of the field is part of (inclusion) or not part of 
(exclusion) the specified collection 

• : format - validates the field against a regular expression 

• : length - validates the length of the field 

• : numerical ity - validates the field if it’s a number. Can also check if it’s a float or an integer. 

• : uniqueness - validates whether the field is unique in the table 

These validation methods typically have the following options: 

• : message - allows you to replace the default message. For example you want to change the “can’t 
be blank” message for validates_presence_of, you can use: 

validates :name, presence: true, message: "is required" 

• :on - specifies when this validation is active (default is :save, other options are : create and 
: update). 

• : al low_ni 1 - skips the validation if the attribute is ni 1 

• : i f, : unless - specifies a method, Proc or string to call to determine if the validation should (: i f) 
or should not (: unless) occur. The method or Proc would be evaluated, while the string would be 
converted to ruby code then evaluated. 

Aside from those validations, you can also use validate, validate_on_create, and val idate_on_update 

to define your own validations. These methods are used just like before_f i Iter is used in controllers. 

class Employee < ActiveRecord :: Base 
val idate_on_create : check_status 

private 

def check_status 

if status == "Suspended" 

errors . add (: status, "can't be Suspended when creating a new Employee") 

end 

end 


end 
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Each Active Record object has anerrors collection containing the errors collected during validation. In 
the case above, we added a new error to the name field. Not only will this determine the complete error 
message to be displayed (the field name is added at the beginning of the message), this will also mark the 
field as an error on the form as we shall see later. 

For error messages that aren’t applicable to a single field, you can use errors [base] : 
errors [base] << "You must specify a contact number or an e-mail address" 


If you want to populate the errors collection without saving the object, you can call validate on the 
object. The methods for checking whether the object is valid or not, valid? and invalid?, also call 
validation. 

Additional methods for errors can be found in the API docs under Act i veRecor d : : Er r or s . Here are some 
of the more commonly used errors methods: 

• [ ] - returns an array of errors for a specified field 


> > 

p = Product. new 


=> 

#<Product id nil, name: 

nil, . . .> 

> > 

p . val id? 


=> 

false 


> > 

p . errors [ : name] 


=> 

"can't be blank" 


• size 

- returns the number of errors in the collection 

> > 

p Product. new 


=> 

#<Product id nil, name: 

nil, . . . > 

> > 

p . errors .size 


=> 

0 


> > 

p . val id? 


=> 

false 


> > 

p . errors .size 


=> 

2 



• clear - removes all errors in the collection 

Transactions 

You can group database actions into transactions by putting them inside a transaction block: 
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begin 

ActiveRecord : Base . transaction do 
source_account . withdraw(10000) 
dest_account . deposit (10000) 

end 

rescue 

# some error handl i ng 

end 

In this transaction method call, a rollback would be issued if an exception is thrown inside the block. 
Since this is a class method of ActiveRecord: :Base, you can switch out the ActiveRecord: : Base with 
any model class, for example: 

Account . transaction do 

end 

You can also use a model object: 
source_account transaction do 
end 

The only problem with using this shorter form is that inexperienced developers might think that the 
transaction is in the Accounts table level. In reality, the transaction is in the database level; you can use 
different tables in the transaction: 

Student . transaction do 
student . save ! 
course . save ! 

end 

You can also nest transactions. By default all database actions inside the nested transactions are part 
of the parent transaction. You can pass the option :requires_new => true to create a sub-transaction 
which would roll back only up to the start of the sub-transaction. Either way, the behavior still depends 
on the database used. For example, if we are using MySQL in the following nested transactions without 
: requires_new: 


Product . transaction do 

Product . create( : name => ' Test ' ) 

begin 

Product . transaction do 
Product . create( ' Test2 ' ) 
Product . create ! ( ) 

end 

rescue 

end 


end 
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would not rollback any transaction i.e. “Test” and “Test2” are created. Using :requires_new => true 
would create a SAVEPOINT between “Test” and “Test2” so only “Test” is successfully committed after the 
exception at Product . create ! : 

Product . transaction do 

Product . create( : name => ' Test ' ) 

begin 

Product . transaction( : requires_new => true) do 
Product . create( ' Test2 ' ) 

Product . create ! ( ) 

end 

rescue 

end 

end 

We enclosed the sub-transaction with a begin-rescue because all exceptions are still propagated 
upward after the rollback is processed. The only exception that is not propagated by the transactions 
is ActiveRecord : : Rollback. For example, the following will behave the same as the previous example 
even without the rescue block: 

Product . transaction do 

Product . create( : name => ' Test ' ) 

Product . transaction( : requires_new => true) do 
Product . create( ' Test2 ' ) 
raise ActiveRecord :: Rol lback 
end 
end 


Ruby Corner - Exception Handling 

The exception handling structure for Ruby, beg in- rescue - e 1 se - ensure - end , is similar to the try - catch - final 
structure in Java and C#: 

begin 

# attempt doing something 

rescue 

# handle the exception 

else 

# do this if no exception was raised 

ensure 

# do this regardless if there was an exception or not 

end 

You can have namedrescue blocks to perform different handling depending on the class of the error 
raised: 

begin 

# attempt doing something 
rescue RuntimeError 

# handle the RuntimeError 
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rescue TypeError 

# handle the TypeError 

else 

When inside therescue block, the object representing the current exception is placed in a global variable 
named $ ! . You can change this name by defining another local variable in the rescue block: 

begin 

# attempt doing something 

rescue RuntimeError 

puts "A runtime error occurred: *{$!}" 
rescue TypeError => t_error 

puts "A type error occurred: **{t_error}" 

else 

You can throw error objects using the raise keyword. In its basic form, raise accepts an exception class 
followed by an optional message. You can also skip the class to use RuntimeError. 

irb(main) :001 :0> raise "This is a runtime error" 

RuntimeError: This is a runtime error 
from ( irb) : 1 
from : 0 

irb(main) :002 :0> raise ZeroDivisionError , "Hello I am a random zero division error" 
ZeroDivisionError : Hello I am a random zero division error 
from ( irb) : 2 
from : 0 

irb(main) : 003 : 0> raise TypeError 
TypeError : TypeError 
from ( irb) : 3 
from : 0 


Action Controller 

We’ve had extensive discussions on Action Controller so the topics below aren’t that complicated. 

Root Routing 

We’ve discussed almost everything about routing, from match to nested resources. The other options 
available for match and resources aren’t that important so just refer to the Routing API docs if you need 
to use them. 

However, you might miss one important routing method while reading through references: the root 
method. For example: 

root to: ' pages # main ' 

root ' pages#main' # shortcut for the above 

This method is basically just another named route so all of the options available formatch would work in 
it. What’s special about it is that it maps the root of your application to a controller action. 
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Going to http : //local host : 3000/ won’t immediately direct you to the main action of pages, though. As 
you may recall in the introduction and our asset tags lesson, the /public folder is mapped to the root, 
and like many web servers, WEBrick and Unicorn will serve you /public/index. html when you access 
the root. 

To make your root route work, you must first delete/pub lie/ index, html. As a named route, you can 
also use the generated helpers root_url and root_path in your controllers and views. 

Multiple Representations 

You might be wondering about the purpose of this code fragment in our Debts program: 

def destroy 
§debt . destroy 

respond_to do I format I 

format html { redirect_to debts_url } 
format.json { render : no_content } 
end 
end 

The respond_to block is processed depending on the MIME type requested by the user, that is, the 
blocks inside the format. xxxx calls are processed when they mach the format requested by the user. 
In format . json, head : no_content was called: only a successful response with no content is returned. 

In the absence of a block, the default rendering is performed. Thus, in the case of the empty show action, 
show . html . erb was used to render the Show Debt page. Similarly, since we did not provide the block for 
JSON, the show .json . jbui lder JSON builder would have been rendered as the response for a request for 
an JSON. 

Typically, the MIME type request is determined through the Accept request header. A browser would 
typically send an Accept header like this: 

Accept : text/html , appl ication/xhtml+xml , appl ication/xml ; q=0. 9, */* ; q=0 . 8 


and Rails would determine the format as html . In the next chapter, we shall see a request with an “Accept : 
text/javascr ipt, ...” that would be handled in a format . js block. 

Most browsers don’t allow the user to define the Accept request header. Thus, Rails provides a way to 
define the format through the : format parameter in routes. For example: 

get ' : control ler (/ : action(/ : id( . : format) ) ) ' 

The parsed : format parameter overrides the Accept header and tells respond_to what format to render 
and return to the user. So going to http://localhost:3000/promos/show/l .xml would process the 
format. xml block inside theshow action of the promos controller, hopefully returning an XML version 
of the 1st promo in the database. 

This format parameter is already added to your routes if you used resource or resources. 
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Cookies and Sessions 

HTTP is a stateless protocol. Because of this, all web application platforms and web frameworks have 
their own means of storing the user’s state without having to go to the database. In this part, we will be 
discussing Rails’ implementation of the two most common state persistence schemes: cookies and sessions. 

Cookies 

You can set and retrieve cookies in the user’s browser using the cookies hash available in the controller. 
Accessing the hash would read the request while manipulating the hash would modify the response. 

* returns the value of the "username" cookie 
cookies [ : username] 

# sets the "theme" key to "blue" 
cookies [: theme] = "blue" 

Cookies can only store string keys and values. You can configure a cookie’s settings by passing 
a hash instead of a string for the value. (The available settings are listed at the API docs under 
ActionControl ler : : Cookies) 


* Sets a cookie that expires in 1 hour. 

cookies [: login] = { : value => "XJ-122", : expires => 1 . hour from_now } 

The delete method can be used to manually delete cookie entries, 
cookies . delete : theme 

Session 

Like other frameworks, Rails sessions differ from cookies in that while you can only store strings in 
cookies, you can store (serializable) objects in the session. Unlike other frameworks, however, Rails does 
not (by default) store the data in the server. Instead, it stores the data as cookies in the user’s browser. 

While the idea of cookie based sessions might sound weird, there are important reasons behind it. First, 
the 4KB limit of cookies and the transparency of cookies promotes good practice: large session objects that 
contain sensitive data are avoided. Also, since the browser handles the cookie expiry, the server doesn’t 
need to waste processing cycles on session cleanup. 

One valid concern about cookie based sessions is that cookies can easily be tampered with. To get around 

this, Rails cryptographically signs the session (you can find the Rails generated key at con f ig/initial izers/session_- 

store . rb). The users can read the session values but they cannot tamper with them. 

With the background out of the way, let’s proceed with using the session. 

Using a session is easy; it’s simply a hash, session, available in the controller and the view (just like params 
and flash). 

session [: current_user] = user 

You can remove a session entry by setting it to nil. You can reset the entire session using the reset_- 
session method. 
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Action View 

We’ve already discussed almost all of the topics regarding Action View. Here, we’ll just wrap up the topic 

of form helpers and displaying form errors. 

Other Form Helpers 

We’ve already covered label, text_f ield, text_area, col lection_select, and submit form helper tags. 

Here are the other form helper tags: 

• check_box - creates a check box for the specified field. It uses the default values for boolean form 
fields in Rails (“l” for true, “0” for false) so if you’re using the check box for non-boolean values, 
you can change the “checked” and “unchecked” values through the arguments. 

• f i le_f ield - creates a file upload input tag. Uploading files is not part of the scope of this training 
course. 

• radio_button - creates a radio button input tag. The radio buttons are grouped according to the 
specified field. 

• hidden_f ield - creates a hidden input tag. 

• password_f ield - creates a password-type input tag. 

• date_select, datetime_select, time_select - produces a set of select tags (e.g. hour, month, etc) 
for the date/datetime/time field. 

Full details canbe found at the API under ActionView : :Helpers: :FormHelper andActionView : :Helpers: :DateHelper. 

Active Support Time Extensions 


We encountered an Active Support extension to Ruby in the form of “blank?”. The rest of the Active 
Support extensions can be found in the API docs under ActiveSupport : : CoreExtensions. In this section, 
we’ll focus on the changes made by Active Support related to numbers and time. 

In Rails, all numbers have methods that make it look like they are being converted to time objects. Here 
are a few examples: 


Time now + 1 minute 
1 . minute . since(Time . now) 
1 . minute . from_now 
Time now 2 days 
2 days . ago 


* returns the time i minute from now 

* also returns the time 1 minute from now 

* still returns time 1 minute from now 

* returns the time 2 days ago - 

* also returns time 2 days ago 


Rails also has support for time zones. The default time zone is set in conf ig/application . rb in the line: 


conf ig . time_zone = 'UTC' 

This assumes that the server, as well as the user, is using UTC. Typically, you set the time zone value per 
user programatically inside a filter: 
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class ApplicationController < ActionControl ler : : Base 

before_f i Iter : set_time_zone 

def set_time_zone 

Time. zone = session [: time_zone] 

end 


The time zone setting not only changes how the time zone is displayed (e.g. if you use the %Z format in 
Time. strf time), it also affects how records are stored in the database for the user. For example: 

Datetime entered by the user Datetime saved in the database Datetime displayed the next 

(Time Zone = UTC +08:00) (Time Zone = UTC +00:00) time the user views the record 

06/12/10 01:00 PM 06/12/10 05:00 AM 06/12/10 01:00 PM 

This handling saves us the hassle of manually converting time input from foreign users to UTC and back. 
Rails also handles daylight saving time, yet another possibly problematic issue for time zone handling. 

Running rake time : zones : al 1 returns all the possible values for the time zone. You can also use rake 
time : zones : local to view the possible values based on your computer’s region settings: 

$ rake time : zones : local 
(in /home/user/al ingnena-app) 

* UTC +08:00 * 

Beijing 
Chongqing 
Hong Kong 
Irkutsk 
Kuala Lumpur 
Perth 
Singapore 
Taipei 

Ulaan Bataar 
Urumqi 

Most of the time, you’ll probably set the default setting at theconfig/application.rb to: 


conf ig . time_zone = 'Taipei' 


Ajax 

Ajax (formerly known as Asynchronous JavaScript and XML) is a set of technologies used to improve the 
user’s experience when browsing websites. It does this by allowing the users to perform actions and let 
the browser and server handle it in the background instead having them go from page to page. This makes 
the user interfaces in websites more dynamic and responsive to the user. 

At the core of Ajax is JavaScript which can send requests to the server in the background thanks to the 
XMLHttpRequest (XHR) object, and can modify the page based on the results thanks to the Document 
Object Model (DOM). There are 4 main approaches to Ajax depending on how XHR and DOM are used: 

1. status codes - XHR sends the request and DOM modifies the page based on the HTTP status code 
returned by the server. 

2. page fragments - XHR sends the request and the server returns a fragment of an HTML page. DOM 
inserts this fragment somewhere in the current page. 

3. code fragments - XHR sends the request and also requests for a JavaScript response. The returned 
data is in the form of JavaScript code that will modify the page through DOM which is then executed 
by the browser. 

4. data - XHR sends the request and also requests for a specific format (e.g. XML, JSON). The server 
returns data in the requested format, which will then be processed by JavaScript in the page. This 
will eventually lead to DOM calls to change the page’s contents. 

Manually coding XHR and DOM calls can be hard. Fortunately, there are JavaScript libraries available 
to make these tasks easier. In this tutorial, we will discuss the two approaches available in Rails: using 
the built-in unobtrusive j Query-powered ajax functions i.e. number 3 above, and Turbolinks which is 
basically number 2 above but sending entire pages. 

Using jQuery with Rails 

To demonstrate the basic uses Rails built-in jQuery functions, we’ll use a simple shoutbox program that 
allows visitors of Aling Nena’s website to leave a message for all to see: 
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----- -- mm 

AlingnenaApp 


^ C O localhost:3000/messages 

☆ A 

Aling Nena's Shoutbox 

Name 

|coder 

Message 
hello po! 



Create Message 


Messages 

Jhun said (1 minute ago): I won't be able to pay this week, sorry :( 
Nene said (2 minutes ago): hello Aling Nena! 

Bong said (4 minutes ago): hello Aling Nena! 


The program is straightforward: a user can submit his/her name and a message which will be added to 
the list on the page. 


wj AlingnenaApp \<G 


^ C 1 O localhost:3000/messages 

☆ * 

Message was successfully created. 

Aling Nena's Shoutbox 

Name 

1 

Message 



Create Message 

Messages 

Coder said (less than a minute ago): hello po! 

Jhun said (1 minute ago): I won't be able to pay this week, sorry :( 
Nene said (2 minutes ago): hello Aling Nena! 

Bong said (4 minutes ago): hello Aling Nena! 


By now you should be able to code this on your own, but if you still can’t, just study the code snippets 
below to have an idea on what you need to do. 

jQuery basics 

Let’s run through the basics of jQuery before we proceed with the Ajax concepts. Add the following code 
at the end of /app/assets/javascripts/appl ication . js: 
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$(document) . ready( function( ) { 

// do stuff 

}); 

Here we can see the first major feature of jQuery: you can register functions that would handle element 
events. In this case, we assigned a function to the ready event of thedocument element of the page. This 
function would be called when thedocument is ready - something like window, on load but works even 
before all images are loaded. 

We could add an alert call to test if it’s working 125 : 

$(document) . ready( function( ) { 
alert ("hello world!"); 

}); 

Open Aling Nena’s Shoutbox to see this code in action. 

Two things to note about this basic code: first, the $ is an alias for jQuery, thus the call $( document) calls 
the constructor for jQuery and in turn creates a jQuery object based ondocument. This basically extends 
the document object, allowing us to use jQuery functions like the ready event handler we used. 

Another thing is the use of an inner function. You could extract the inner function to another function 
when it becomes more complicated, but since we’ve been using Procs and Blocks already in Ruby, you 
should be comfortable with using them for simple tasks. 

Using alert for the “hello world!” program doesn’t do justice to jQuery’s capabilities. Let’s modify the 
program to make it more j Query-friendly 126 : 

$(document) . ready( function( ) { 

$("#notice") ,text("hello world! "); 

}); 

Here we see the second major feature of jQuery: you can select elements from the page with CSS 
selectors. Here we selected the p element with id="notice" and called the jQuery manipulation function 
text( ) to change the text of the element to “hello world!”. 

Just like in CSS, selectors can match multiple elements. Calling jQuery functions or registering handlers 
to a jQuery object will apply those functions and handlers to all elements that the object refers to. For 
example, using 127 


125 https://github.com/bryanbibat/rasm40code/commit/e762bf24412261710df7e9f32fd65017451adld5 

126 https://github.com/bryanbibat/rasm40code/commit/c8bl8c6aa4725elebb9b35lbff4ee97b08524bdf 

127 https://github.com/bryanbibat/rasm40code/commit/ldb4aflbbc76dfalaf55cd0966lffedfl6380240 
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$(document) . ready( function( ) { 

$("li") ,css( "color", "blue"); 

$("li") . mouseover( function () { 

$(this) . css ( "color" , "red"); 

} ) . mouseout( function( ) { 

$(this) . css ( "color" , "black" ) ; 

}); 

}); 

Will first set thecolor CSS attribute of all 1 i elements to blue. We then registered the mouseover event 
handler that would set thecolor to red when the mouse is over the element. Finally, since the mouseover 
function returns the same jQuery element, we can chain another function, this time setting the mouseout 
handler to turn the element to black when the mouse leaves the element. 

Now that we’re familiar with jQuery, let’s proceed with Ajax. 

Preparing the Page fragment 

In this lesson, we want to modify the page so that we could refresh the table to show the new messages 
without having to refreshing the entire page. The easiest way to do this in Rails 3 would be to use the 3rd 
Ajax approach, that is, to create JavaScript code which will insert the updated list inside the page, then 
use jQuery to retrieve run that code. 

The first part is easy. We just have to add a new action: 

# conf ig/routes . rb 128 


resources : messages do 

collection do 

get ' message_table ' 
end 
end 


# app/control ler/messages_control ler . rb 129 
def message_table 

render partial: Message . order ( "created_at DESC") 

end 

and partial for the list: 

# app/views/messages/index . html . erb 130 


128 https://github.com/bryanbibat/rasm40code/commit/lc563ae7acd7f88577d5a925e0e21749819a8a86#diff-3 

12s, https://github.com/bryanbibat/rasm40code/commit/lc563ae7acd7f88577d5a925e0e21749819a8a86#diff-0 

130 https://github.com/bryanbibat/rasm40code/commit/lc563ae7acd7f88577d5a925e0e21749819a8a86#diff-2 
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<h2> Messages </h2> 

<ul sty le=" list -style- type : none; font -size: 125%; 1 ine- height : 150%" id="message_list"> 
<%= render partial: @messages %> 

</ul> 

# app/views/messages/_message . html . erb 131 
< 1 i > 

<strong><£= message author %> said</strong> 

<em>(<Z= time_ago_in_words( message. created_at) %> ago)</em>: 

<%= message . message %> 

</li> 

The partial can now be accessed at http : // loca 1 host : 3000/messages/message_table 



The second part is also easy but will require a bit more effort. 

Updating a Part of the Page via remote link_to 

We need to modify the controller to add a JS handler: # app/control ler/messages_control ler . rb 132 
def message_table 

@messages = Message order( "created_at DESC") 
respond_to do I format I 
format . js 

format html { render partial: §messages } 
end 
end 

And create a message_table . js . erb 133 file that will contain the code to update the message table: 

$( "#message_l ist" ) . html ( " <%- escape_javascr ipt( render partial: §messages ) %>"); 

Then, all that’s left to do is to add this link to our page: 

# app/views/messages/index . html . erb 134 

131 https://github.com/bryanbibat/rasm40code/commit/lc563ae7acd7f88577d5a925e0e21749819a8a86#diff-l 

132 https://github.com/bryanbibat/rasm40code/commit/c9el882f82cfca79bl5522b6ee50728dba68876a#diff-0 

133 https://github.com/bryanbibat/rasm40code/commit/3605d9218e419d9dd5e55284cf0f46ccbcb9e5d4#diff-3 

134 https://github.com/bryanbibat/rasm40code/commit/c9el882f82cfca79bl5522b6ee50728dba68876a#diff-l 
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<%= link_to "Refresh List", message_table_messages_path, remote: true %> 


The : remote => true option tells Rails that the link should be processed as an AJAX call and not as a 
normal link. When you click the “Refresh List” link, it will process the JavaScript returned by our app, 
and in turn replacing the contents of the message table. 


1 

1 'TT' fol 

i 



1 «- 

© localhost:3000/messages/message_table & 

- 


• Coder said (2 minutes ago): hello po! 

• Jhun said (3 minutes ago): I won't be able to pay this week, sorry :( 

• Nene said (4 minutes ago): hello Aling Nena! 

• Bong said (6 minutes ago): hello Aling Nena! 


Form submission via Ajax 

Let’s move on from the simple GET example to a slightly more complicated POST example. Here we’ll 
convert our form to use Ajax. 

First, modify the create action to add the JS responders: 

# app/control lers/messages_control ler . rb 135 


def create 

©message : Message . new(params [: message] ) 

respond_to do I format I 
if ©message . save 

format.html { redirect_to messages_path, 

notice: ’Message was successfully created.' } 
format. json { render action: 'show', status: :created, location: ©message } 

format. js { ©messages = Message order ( "created_at DESC") } 
else 

©messages = Message . al 1 (order : "created_at desc") 
format.html { render action: 'new' } 

format. json { render json: @message . errors, status: : unprocessable_entity } 

format. js { render text: 

"$( '*notice' ) ,show() .html( 'There was an error in creating the message.')" } 
end 
end 
end 
end 


Then we create our new create . js . erb 136 view: 


135 https://github.com/bryanbibat/rasm40code/commit/3605d9218e419d9dd5e55284cf0f46ccbcb9e5d4#diff-0 

136 https://github.com/bryanbibat/rasm40code/commit/3605d9218e419d9dd5e55284cf0f46ccbcb9e5d4#diff-l 
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$( "#message_l ist" ) . html ( " <%= escape_javascript( render partial: §messages ) %>"); 
$( "^notice" ) . show( ) 

. html ( "Message was successfully created delay(20000) . fadeOut( "slow" ) ; 

$( "#new_message" ) [0] . reset( ) ; 

This also adds a fade-out animation after 20 seconds. 

We also need to update our view in order for the Ajax call to work. 

# app/views/messages/index . html . erb 137 

<p id="notice " > <%= notice %></p> 

<%= form_for(§message, remote: true) do |f| %> 

<P> 

<%= f label : author, "Name" ^><br /> 


Just like in link_to, we only needed to add a remote: true option to tell Rails to process the form 
submission as an Ajax call. 

Trying out the code will result in the following: 



It looks like it behaved normally, but if you use the Mozilla Firefox extension Firebug or Google Chrome’s 
Developer Tools (Tools -> Developer tools), you’ll notice something different about the request and 
the response. 


137 https://github.com/bryanbibat/rasm40code/commit/3605d9218e419d9dd5e55284cf0f46ccbcb9e5d4#diff-2 
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From the request headers, we could see that it’s using XHR and Prototype. However, the important thing 
here to note is the text/javascr ipt in the Accept header which tells Rails the format the request requires. 



As for the response, there’s nothing unusual about the headers aside from the explicit disabling of caching. 


Unobtrusive JavaScript and graceful degradation 

Before we move on to Turbolinks, you may want to take note that the JavaScript used in the examples 
above are not inline scripts. In other words, the a and form elements are still basic HTML without any 
JavaScript within them: 
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<form accept-charset="UTF-8" action="/messages" class="new_message" 
data-remote="true" id="new_message" method="post"> <div style= 

"margin : 0; padding : 0; display : ini ine"> < input name="utf8" type="hidden" 
value="&#x2713; " /></div> 


<a data-remote="true" href="/messages/message_table">Refresh List</a> 

What jQuery does is look at the elements after the page has loaded and check if the data-remote attribute is 
set. When set, jQuery adds the necessary event handlers for these elements. Some people call this approach 
“unobtrusive JavaScript” or UJS, in contrast to old “obtrusive” ways of adding JavaScript into elements 
via inline scripts. 

Aside from being cleaner, UJS has better support for disabled JavaScript. Remember, Ajax’s primary goal 
is to improve user experience. Therefore, it does not make sense for a program to stop working if the user 
disables JavaScript in his/her browser. 

With UJS, one could easily see what would be the behavior in case the JavaScript is disabled. In our 
example above, link_to will just open a list of messages (we could easily redirect this back to index) 
while form_for will just behave like it used to. 

Simple polling implementation 


To wrap up this lesson, let’s modify the “Refresh List” code to use jQuery. Also, instead of making the user 
click the link, let’s modify the page such that it automatically polls the server at certain intervals. We first 
remove the link from the page 138 : 


end Z> 

<Z~ link_to "Refresh List", — mossago_tablo_mossagos_path, — remote : — true % > 

<h2> Messages </h2> 

Then we add the polling code to application . js 139 : 

$(document) . ready/ function/ ) { 
if ($( "#message_l ist" ) . length) { 
setlnterval/ function/) { 

$ . getScript/ "/messages/message_table . js" ) ; 

}, 60000 ); 

} 

}); 

Here we just used the JavaScript function setlnterval/) to make an Ajax call every minute (60,000 
milliseconds). The actual call is done by jQuery’s getScript / ) function which makes an asynchronous 
GET call and executes the returned data as JavaScript. 

138 https://github.com/bryanbibat/rasm40code/commit/9f9db60d8110f08b50c59da8b8305f2623bb08f0#diff-l 

139 https://github.com/bryanbibat/rasm40code/commit/9f9db60d8110f08b50c59da8b8305f2623bb08f0#diff-0 
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Turbolinks 

Back when we introduced the JavaScript asset tags, we mentioned that both jQuery and Turbolinks are 
added to Rails by default. We’ve already discussed jQuery so let’s give a quick intro to Turbolinks. 

Turbolinks converts all GET links into Ajax calls like the one we did for the “refresh list”. However, instead 
of replacing just a fragment of the page, Turbolinks replaces the entire page via the Ajax call and modifies 
the browser state/URL with the target page. If the browser does not support PushState for manipulating 
browser history and state, Turbolinks will fall back to normal link GET behavior. You can verify this by 
opening your browser’s developer tools and clicking on any “Show” link, for example the “Show Product” 
link: 



As you can see, this can theoretically reduce a page load down to a single HTML GET - all CSS and JS 
that apply to the old page will just be reused. Looking again at the layout code, we see how Turbolinks 
decides what assets to load: 

<%= stylesheet_l ink_tag "application", media: "all", 

"data-turbol inks-track" => true %> 

<%= javascript_include_tag "application", "data-turbol inks-track" => true %> 

In production mode, the data-turbol inks-track option tells Turbolinks to track the asset based on its 
fingerprint. We’ll discuss fingerprinting later at the Asset Pipeline discussion, but basically this allows 
Turbolinks to check if the asset was updated or not. It will only load the asset if it was updated. 

Note that enabling Turbolinks would mean that many of your JavaScript code that runs on page load 
will not load when Turbolinks retrieves and loads a page. They will have to be modified to work with 
Turbolinks 140 to use the page: change event e.g.: 


14 °https://github.com/bryanbibat/rasm40code/commit/e94dl7214310a2f9fb34246d9aaa7cfllll29al4 
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$(document) .on("page:change", function() { 

if ($( "#message_l ist" ). length) { 
setlnterval( function() { 

$ . getScr ipt( "/messages/message_table . js" ) ; 

}, 60000 ); 

} 

}); 

If you’re using many third-party JavaScript code, it may be difficult to convert them to support Turbolinks. 
At the worst case, you can disable Turbolinks by removing the references in your appl ication . js as well 
as your Gemf ile. (Modifying your Gemf i le will require a bundle update to refresh it.) 


Automated Testing with RSpec 

In this chapter, we will cover the basics of automated testing with RSpec. 

Overview to Automated Testing 

In traditional software companies, employees are separated into silos according to their purpose: analysts 
design the system which they pass to developers. The developers code the programs and pass them to QA. 
The testers test the programs then pass the final working system to Operations. 

When a developer from this “assembly-line” encounters the terms “Test Driven Development” or 
“Automated Testing”, they often ask the same question: 

“We already have testers, and we even do developer testing before passing our programs to QA. Why 
should we spend time programming tests for our programs?” 

The answer here always boils down to “immediate feedback”. 

Say for example you have a simple table maintenance program. A competent developer can program that 
in an hour and spend maybe 5 minutes to fully developer test the program before passing it to QA. In this 
case, coding test for the program feels like a waste of time. 

But what if this maintenance program has is slightly more complicated than usual? Maybe there’s special 
handling when the record is saved, or maybe some the flow changes depending on some factors, or maybe 
the page displays different data on some other factors. Here the combined testing time for the developer 
and tester might take 30 minutes. 

Now what if the modules of that program are used and modified by a new program? In addition to testing 
the new program, you will have to do some regression testing on the old program, maybe pulling the total 
testing time up to an hour. 

As the system becomes larger and larger, and the modules become more and more interconnected, full 
regression tests are no longer done except on major releases: no project manager on their right mind would 
ask the QA team to do a full regression test consisting of a total of over 1,000 test cases for every minor 
change in the system. 

The end result here is always the same: bugs creep into the system and they’re reported weeks or months 
after the change that caused them was applied to the main build. 

Automated tests do not guarantee that bugs won’t creep into the system. However, they allow the team 
to detect more bugs and detect them much earlier than manual testing would have. 

What would happen if those over 1,000 test cases were automated? 

In the developer side, maintenance is no longer like struggling out of quicksand or a tar pit. When 
maintaining fairly complicated programs, fixing 1 bug produces 2 more bugs somewhere else. Without 
automated tests to tell you what program you broke because of your fix, those bugs might go undetected 
for weeks, decreasing the overall stability of the system. 

With automated tests, you could immediately know the side effects of your change and act accordingly: 
either you fix your change or fix the tests that failed because of the new behavior. 
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In the QA side, the testers are now free from doing trivial and mechanical testing tasks. Instead of testing 
if the name field is mandatory for the 100th time, they could spend their time doing exploratory testing, 
looking for obscure test cases which aren’t handled by the current test suite. 

In the end, it’s all about the return on investment. Your developers are going to spend more time 
programming because of the tests, but as every software engineer knows, most of the effort is in the 
bug fixing and maintenance. In large and complicated systems, the return on investment in terms of time 
and effort is so high that teams who have experienced using automated testing for their projects would 
never think about going back to full manual testing. 

RSpec 

Rails has a built in testing framework based on Test::Unit. For this course, we’re going to be using a 
different framework, RSpec. 

RSpec is a Behavior Driven Development (BDD) framework. For this lesson, however, we will be using it 
as a Test Driven Development (TDD) tool. We will discuss the difference between BDD and TDD at the 
end of this chapter, but we can point out some of the differences between the Test::Unit and RSpec right 
now: 

• “Assertions” are now “expectations”, “test methods” are “code examples”, and “test cases” become 
“example groups”. This change in semantics reduce the confusion between developer and QA ideas 
on testing, as “expectations” and “examples” imply that we are also doing design and documentation 
work, while tests simply imply that there is a function in the system that needs to be tested. 

• Specs (files containing one or more example groups) in RSpec are much more human-readable than 
Test::Unit tests. Well written specs can even be forwarded to your analysts (or even users) for them 
to verify if the specifications are correct. 

Note that we will be using RSpec-2 for this course so many online tutorials and documentation may not 
be applicable. Please refer to the official docs 141 for the up to date information. Also note that RSpec-3 
is just around the corner and some of the syntax here may not be applicable by the time you read this 
manual. 

Installing RSpec 

To install RSpec, just addrspec-rails under a : development and : test group inGemf ile and let Bundler 
find and install the necessary dependencies. Flere are the lines you need to add to the Gemf i le 142 : 

group development, :test do 
gem 'rspec -rails' , ’~> 2.14.1' 
gem 'webrat', 1 ~> 0.7.3' 
end 

Note that we also added Webrat, an integration testing tool which we will use over Test::Unit for testing 
views. 

Run bundle install to install rspec -rails, webrat and their dependencies. As with many Rails plugins, 
we also need to run a script to install RSpec to your application: 

141 http://relishapp.com/rspec 

142 https://github.com/bryanbibat/rasm40code/commit/8376f734b76497f91cd0fd7eb96182390e5cc051#diff-l 


Automated Testing with RSpec 


154 


$ bundle install 

Your bundle is complete! 

Use 'bundle show [gemname] ' to see where a bundled gem is installed. 

$ rails generate rspec : instal 1 
create .rspec 
create spec 

create spec/spec_helper . rb 

As with all Rails test frameworks, tests are executed in the “test” environment as opposed to the default 
“development” environment. This makes sense because you might want to create specs like “delete all 
records from table xxxx” and you don’t want to let your development test data to be deleted every time 
you run your tests. 

To modify your test environment database settings, go to config/database.yml and edit the settings 
under test. 

You might have noticed that in the Gemfile we placed rspec-rails inside a group declaration. Unlike 
jquery-rails, we only use RSpec in development (when we run the generator scripts) and test (when 
we perform the actual tests). In all other cases, like production and staging environments, RSpec is not 
necessary. By specifying the correct environment for the gems, we prevent those gems from being installed 
by Bundler or used by Rails in other environments. 

RSpec Generator Scripts 

Once rspec-rails is added to your application, the generator scripts for scat fold, model and control ler 
are already modified to generate RSpec files instead of the default TestaUnit files. 

Let’s try creating a new program now with the updated scaffold script (you can create a new Rails 
application for this, we will not be referencing the other programs in this chapter, just don’t forget to do 
the steps in the previous section): 

$ rails generate scaffold customer name: string active : boolean --webrat 
invoke active_record 

create db/migrate/2014xxxxxxxxxx_create_customers . rb 
create app/models/customer . rb 

invoke rspec 

create spec/models/customer_spec . rb 

invoke resource_route 
route resources : customers 

invoke scaf fold_control ler 

create app/control lers/customers_control ler . rb 

invoke erb 

create app/views/customers 

create app/views/customers/index . html .erb 

create app/views/customers/edit . html . erb 

create app/views/customers/show . html . erb 

create app/views/customers/new . html . erb 

create app/views/customers/_form . html .erb 

invoke 


rspec 
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create spec/control lers/customers_controller_spec . rb 

create spec/views/customers/edit . html . erb_spec . rb 

create spec/views/customers/ index . html .erb_spec . rb 

create spec/views/customers/new . html . erb_spec . rb 

create spec/views/customers/show . html . erb_spec . rb 

invoke helper 

create spec/helpers/customers_helper_spec . rb 

create spec/routing/customers_routing_spec . rb 

invoke rspec 

create spec/requests/customers_spec . rb 

invoke helper 

create app/helpers/customers_helper . rb 

invoke rspec 

create spec/helpers/customers_helper_spec . rb 

invoke jbuilder 

create app/views/customers/index . json . jbui lder 

create app/views/customers/show . json . jbuilder 

invoke assets 
invoke coffee 

create app/assets/javascr ipts/customers . js . coffee 

invoke scss 

create app/assets/sty lesheets/customers . css . scss 

invoke scss 

identical app/assets/stylesheets/scaf folds . css . scss 

Note that we added the --webrat option in order to generate Web rat expectations inside the generated 
views. 

Now to update the database schema: 

$ rake db: migrate 

If you’re using databases like MySQL, you might have to create the databases first: 

$ rake db: create 
$ rake db: create RAILS_ENV=test 
$ rake db: migrate 

Now you can run the server with rails server, or you can just run the specs that were generated along 
with the entire program with: 

$ rake spec 


You should see something like: 
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** 


Pending : 

CustomersHelper add some examples to (or delete) /home/ubuntu/al ingnena-app/spec/ . . . 

# No reason given 

# . /spec/helpers/customers_helper_spec . rb : 14 

Customer add some examples to (or delete) /home/ubuntu/al ingnena-app/spec/models/ .. . 

# No reason given 

# . /spec/models/customer_spec . rb : 4 

Finished in 1.97 seconds 
30 examples, 0 failures, 2 pending 

Analysis of the Generated Specs 

Let’s look at the generated code per Rails module and introduce various RSpec and testing concepts along 
the way. 

Model Specs 

Model specs are located at spec/models folder and are named [model_name]_spec . rb. Here’s the contents 
of spec/models/customer_spec . rb: 

require ' spec_helper ' 
describe Customer do 

pending "add some examples to (or delete) #{ FILE }" 

end 


The require 1 spec_helper ' call refers to spec/spec_helper . rb which provides the libraries for the spec 
to work and configuration options. Here’s the default generated spec/spec_helper . rb file: 

* This file is copied to spec/ when you run 'rails generate rspec : install ' 

ENV [ "RAILS_ENV" ] ||= 'test' 

require Fi le . expand_path( "../.. /conf ig/environment" , FILE ) 

require ' rspec/rai Is ' 
require ' rspec/autorun ' 

* Requires supporting ruby files with custom matchers and macros, etc, 

* in spec/support/ and its subdirectories . 

Dir [Rai Is . root join( "spec/support/**/* . rb" )]. each { |f| require f } 

* Checks for pending migrations before tests are run. 

* If you are not using ActiveRecord , you can remove this line. 

ActiveRecord Migration check_pending ! if de fined /(ActiveRecord :: Migration) 


RSpec . conf igure do I conf ig I 
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# ## Mock Framework 

# 

# If you prefer to use mocha, flexmock or RR, uncomment the appropriate line: 

# 

# confi g . mock_wi th : mocha 

# con fig . mock_with : flexmock 

# confi g . mock_wi th : rr 

# Remove this line if you're not using ActiveRecord or ActiveRecord fixtures 

conf ig . f ixture_path = "#{ : : Rai Is . root}/spec/f ixtures" 

# If you're not using ActiveRecord, or you'd prefer not to run each of your 

# examples within a transaction, remove the following line or assign false 

# instead of true. 

conf ig . use_transactional_f ixtures = true 

# If true, the base class of anonymous controllers will be inferred 

# automatically. This will be the default behavior in future versions of 

# rspec-rai Is . 

conf ig . infer_base_class_for_anonymous_control lers = false 

# Run specs in random order to surface order dependencies . If you find an 

# order dependency and want to debug it, you can fix the order by providing 

# the seed, which is printed after each run. 

# --seed 1234 

conf ig. order - "random" 
end 


Example Groups 

The next part is the example group which is declared by the describe method. Following the describe 
are the examples declared by the it method. For example, let’s remove the pending declaration and add 
a valid case 143 : 


require ' spec_helper ' 
describe Customer do 

it "should create a new instance given valid attributes" do 

Customer create! (name: 'John', active: false) # will throw error on failure 
end 
end 

One good way of looking at the example group would be to imagine a conversation between you and the 
user. Therefore: 


143 https://github.com/bryanbibat/rasm40code/commit/b225d7ebebf54ace9bfl078783bd9f8d7801536a 
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describe Customer do 

it "should create a new instance given valid attributes" do 

end 

end 

becomes: 

You: Describe [the] Customer [model]. 

User: It should create a new instance given valid attributes. 

For this spec, our example does not have an explicit expectation. All it does is try to save a record with 
valid attributes; the example would fail if thecreate! method throws an error. We will look more into 
expectations when we go into the controller spec. 

Set Up and Tear Down 

Thebefore method contains statements that would be executed before the examples in the group. In testing 
terms, this would be the “set up” method. The option used here is : each which means that the block would 
be executed for every example. Another possible option is : al 1 which runs the block only once before all 
the examples are executed. 

If you need to do things after every example (e.g. delete records created by the example), you could use the 
after method. It has the same options as before, but it executes the block after the examples. In testing 
terms, this would be the “tear down” method. 

Controller Specs 

Controller specs are located at spec/control lers/ and are named [control ler_class] _spec . rb. Here’s 
spec/control lers/customers_control ler_spec . rb , a far more complicated spec than our model spec 
(removed some examples to shorten the code snippet): 

require ' spec_helper ' 

describe CustomersControl ler do 

let( : valid_attributes) { { "name" => "MyString" } } 

let( : val id_session) { {} } 

describe "GET index" do 

it "assigns all customers as ©customers" do 
customer : Customer . create ! val id_attr ibutes 
get : index, {}, val id_session 
assigns( :customers) .should eq( [customer] ) 
end 
end 


describe "GET show" do 
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it "assigns the requested customer as §customer" do 
customer : Customer . create ! val id_attr ibutes 
get :show, { : id => customer . to_param} , val id_session 
assigns( :customer) .should eq(customer) 

end 

end 


describe "POST create" do 

describe "with valid params" do 
it "creates a new Customer" do 
expect { 

post :create, {:customer => val id_attr ibutes} , val id_session 
} . to change(Customer , : count) by(l) 

end 

it "assigns a newly created customer as §customer" do 

post : create, {: customer => val id_attr ibutes} , val id_session 
assigns( : customer) .should be_a (Customer) 
assigns( :customer) .should be_persisted 

end 

it "redirects to the created customer" do 

post : create, {: customer => val id_attr ibutes} , val id_session 
response . should redirect_to(Customer . last) 

end 

end 

describe "with invalid params" do 

it "assigns a newly created but unsaved customer as @customer" do 

# Trigger the behavior that occurs when invalid params are submitted 
Customer any_instance . stub( : save) . and_return( false) 

post : create, {: customer => { "name" => "invalid value" }}, val id_session 
assigns( :customer) .should be_a_new(Customer ) 

end 

it "re-renders the 'new' template" do 

# Trigger the behavior that occurs when invalid params are submitted 

Customer . any_instance . stub( : save) . and_return( false) 

post : create, {: customer => { "name" => "invalid value" }}, val id_session 
response . should render_template( "new" ) 

end 

end 

end 


end 
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Unlike in the model where the first describe was just there to say that we are testing the Customer class, 
the first describe method here defines the Action Controller class that we test on in this spec. If we put 
another controller class there instead of CustomersControl ler, this spec would test the examples on that 
controller instead. 

Also, since we do not test the class directly like in the model, we must simulate requests from the user. 
To do that, we can use the get, post, put/patch, and delete methods inherited from Action Controller’s 
testing methods. These methods accept an action to test and optional hashes for parameters, session, and 
flash. For example: 

describe "GET show" do 

it "assigns the requested customer as ©customer" do 
customer = Customer . create ! val id_attributes 

get :show, { : i d => customer . to_param} , valid_session 

assigns( : customer) . should eq(customer ) 

end 

end 

This spec introduces the concept of nested example groups. You can nest example groups to group similar 
example groups for maintainability and readability (like in this spec) or if you want to group examples so 
that thebefore andafter method calls would only apply to them. 

The “conversation” technique still works with nested examples: 

You: Describe CustomersControl ler [when you send] POST create with valid params . 

User: It assigns a newly created customer as (©customer [and] 
it redirects to the created customer. 

Mocks and Stubs 

Database transactions are often the main bottlenecks in web applications. If all of our examples access the 
database, running specs may take too much time to be practical. 

To avoid this penalty, we test our modules in isolation. In other words, the model specs only test the 
models, the controller specs, the controllers, and the view specs, the views. However, there still lies a 
problem: our controller and view code uses models, so how to we remove the models from them in our 
tests? 

The answer lies in mocks and stubs. 

Mocks are fake objects with the same method signature as the original objects. Because of this, they can 
be used in place of the object anywhere in our tests. Here’s a possible helper method from older versions 
of RSpec that creates a mock customer object: 

def mock_customer(stubs={ } ) 

©mock_customer ||= mock_model (Customer , stubs) . as_nul l_object 

end 

Stubs, on the other hand, are fake methods that return a predefined result. For instance, calling mock_- 
customer( : save => true) will create a stub in the mock object for save( ) which will return true always. 

When you have stubs, there’s also the concept of “stubbing” wherein you replace the functionality of a 
method with a stub. We see this in the POST create example: 
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describe "with invalid params" do 

it "assigns a newly created but unsaved customer as ©customer" do 

# Trigger the behavior that occurs when invalid params are submitted 

Customer any_instance stub( : save) . and_return( false) 

post :create, {:customer => { "name" => "invalid value" }}, val id_session 
assigns( :customer) .should be_a_new (Customer) 

end 

end 

Here the save( ) method of Customer class is stubbed out with a stub that returns false (i.e. the passed 
block). By faking the behavior of the model, we can test if the controller is behaving properly without 
having to access the database. 

Accessing Controller Data 

You can use the following methods in the examples: 

# assigns( : key) - a hash containing the instance variables of the controller. 

# flash [ : key] , session [ : key] - the flash and session hashes of the controller 

Expectations 

Expectations replace assertions in RSpec; instead of using assert (some expression) we add the call the 
should method. For example: 

describe "GET index" do 

it "assigns all customers as ©customers" do 
customer Customer . create ! val id_attributes 
get : index, {}, val id_session 

assigns( customers) .should eq( [customer] ) 
end 
end 

Here RSpec verifies if the ©customers instance variable contains the array of mock_customer after the 
index action is processed. If it does, it passes, otherwise the example fails. This would be the output if we 
replace [customer] with []: 

.* F 

Pending : 

CustomersHelper add some examples to (or delete) /home/ubuntu/al ingnena- 
app/spec/helpers/customers_helper_spec . rb 

# No reason given 

# . /spec/helpers/customers_helper_spec . rb : 14 
Fai lures : 


1) CustomersControl ler GET index assigns all customers as ©customers 
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Failure/Error: assigns( :customers) .should eq([]) 
expected : [ ] 

got: #<ActiveRecord :: Relation [#<Customer id: 1, ... 

(compared using ==) 

Diff : 

@@ -1,2 +1,2 @@ 

-[] 

+[#<Customer id: 1, name: "MyString", ... 

# . /spec/control lers/customers_control ler_spec . rb : 37 : in 'block (3 levels) 
in <top (required):*' 

Finished in 0.74895 seconds 
30 examples, 1 failure, 1 pending 

RSpec provides methods for other cases. For example, we could use thebe method to check for an object’s 
identity (e.g. internal representation) if they are the same object: 

describe "GET show" do 

it "assigns the requested customer as ©customer" do 
customer Customer . create ! val id_attributes 
get :show, { : i d => customer . to_param} , val id_session 

assigns( : customer) .should eq(customer) 
end 
end 

One of the key features of should is that it allows us to make our expectations more human-readable 
than traditional assert calls. For instance, we can further make the expectation above human-readable by 
removing the parenthesis: 

assigns( :customer) should eq(customer) 

Here’s a list of some other expectations: 

target . should satisfy { I arg I ...} 

target . should_not satisfy { I arg I ...} 

target . should not_equal <value> 

target . should be_close <value>, <tolerance> 

target . should_not be_close <value>, <tolerance> 

target . should be <value> 

target . should_not be <value> 

target . should be < 6 

target . should_not eq 'Samantha' 

target . should match <regex> 
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target . should_not match <regex> 

target . should be_an_instance_of <class> 

target . should_not be_an_instance_of <class> 

target . should be_a_kind_of <class> 

target . should_not be_a_kind_of <class> 

target . should respond_to <symbol> 

target . should_not respond_to <symbol> 

A good practice for writing expectations is to write only one expectation per example. This allows you to 
pinpoint exactly where the problem is when your specs fail. 

Isolation and Integration with Views 

By default, RSpec will run your controller actions in isolation from their related views. This allows you 
to spec your controllers before the views even exist, and will keep the specs from failing when there are 
errors in your views. 

If you prefer to integrate views, you can do so by calling integrates iews. 

describe CustomersControl ler do 

integrates iews 

end 

When you integrate views in the controller specs, you can use any of the expectations that are specific to 
views as well. 


Response Expectations 

There are expectations you can use with the response: 
response . should be_success 

Passes if a status of 200 was returned. Note that in isolation mode, this will always return true, so it’s not 
that useful - but at least your specs won’t break. 

response . should be_redirect 

Passes if a status of 300-399 was returned. 

get ' some_action 1 

response . should render_template( "path/to/template/for/action" ) 


Passes if the expected template is rendered. 
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get ' some_action 1 

response . should have_text( "expected text") 

Passes if the response contains the expected text 
get ' some_action 1 

response . should red i rect_to (: action => 1 other_action ' ) 

Passes if the response redirects to the expected action or path. The following forms are supported: 

response . should redirect_to( : action => 1 other_action ' ) 
response . should redirect_to( 1 path/to/local/redirect ' ) 

response . should redirect_to( 1 http : //test . host/some_control ler/some_action ' ) 
response . should redirect_to( 1 http : //some . other . domain . com ' 

View Specs 

View specs are located at spec/views/ [control ler_name]/ and are named like the views with an 
additional_spec . rb suffix. Here’s the contents of spec/views/customers/index . html . erb_spec . rb: 

require ' spec_helper ' 

describe "customers/index" do 
before( : each) do 

assign( : customers, [ 
stu b_mode 1 ( Customer , 

: name => "Name", 

: active => false 

), 

stu b_mode 1 ( Customer , 

: name => "Name", 

: active => false 

) 

]) 

end 

it "renders a list of customers" do 
render 

rendered . should have_selector( "tr>td" , :content => "Name".to_s, :count => 2) 
rendered . should have_selector( "tr>td" , :content => false. to_s, :count => 2) 

end 

end 

Like the controller specs, you define the view to be rendered in the describe of the first example group. 

In this example, we used assign( ) to create fake instance variable containing an array of mock objects. 
By using mocks, we isolate the view from the model. 

Along with the assign, you can also use the session and flash hash that we use in the controller spec. 
Unlike in the controller spec where we could assign the params through the get, post, put or delete calls, 
the params is available in the view specs for modification. 
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rendered. should have_selector 

You can test the contents of the response by using Webrat’s have_selector method. It checks the existence 
of elements matching the specified CSS selector 144 . It also accepts : content and : count options to add 
additional constraints to the pattern search. In our example: 

it "renders a list of customers" do 
render 

rendered should have_selector( "tr>td" , : content => "Name".to_s, : count => 2) 
rendered should have_selector( "tr>td" , : content => false. to_s, : count => 2) 
end 

The first have_selector verifies if there are 2 “Name” inside a <tr><td> element in the response, while 
the second tests if there are 2 “false”. 

Note that as mentioned in the Controller Specs above, have_se lector is available to the controller spec 
if you use the spec in integration mode. 

Mocking and stubbing helpers 

You need to manually include all the helpers used by the view because it doesn’t use the App 1 i cat i onControl 1 er 
where the he 1 per : a 1 1 call resides. 

If you wish to isolate the view from the helpers by creating mock/stubbed helper methods, you should 
use the view object. For example, to stub the display_purchase( invoice) helper we made back in 
Associations: 

view . should_receive( : display_purchase) { ("(no Purchase set)") } 


Helper Specs 

Helper specs are much simpler than the other three spec types so let’s just include them under view. 

You place helper specs at the spec/helpers folder. The naming convention and defining the helper to be 
tested is the same. For example, the spec for the InvoicesHelper we created in the Associations lesson 
would be spec/helpers/invoices_helper_spec.rb 145 and look like: 

require ' spec_helper ' 

describe InvoicesHelper do 

describe "display_purchase" do 

it "should display description of the purchase of the invoice" do 

mock_purchase = stub_model(Purchase, :description => "a description") 
mock_invoice = stub_model ( Invoice, : purchase => mock_purchase) 
helper display_purchase(mock_invoice) . should include "a description" 

end 


144 http://www. w3.org/TR/css3-selectors/ 

145 https://github.com/bryanbibat/rasm40code/corrrmit/da5dbca71b80d4a45fbe2fb6c9f4c91dc94358ed 
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it "should display a default message if there is no purchase" do 
mock_invoice = stub_model ( Invoice, :purchase => nil) 
helper display_purchase(mock_invoice) . should == "(no Purchase set)" 

end 

end 

end 

The helper object was created by RSpec to include the contents of the class (invoicesHelper) we specified. 
(You may want to remove the pending declaration in CustomerHelper in preparation for the next section.) 

Test Driven Development with RSpec 

Let’s demonstrate TDD by adding a few simple features to our Customers program: 

• When you create a Customer, it should be set to Active (active = true) 

• When you delete a Customer, it should not be deleted from the database. Instead it should be set to 
Inactive (active = false) 

• When you view the list of all Customers, only Active Customers shall be displayed 

• When you try to view the details of an inactive record, you should be redirected back to the list of 
Customers 

• The Active field should not be displayed at the list of Customers 

The first two features are all model based, the next two are for controller, and the last is for the view. 

First thing to do is to create pending examples so that we don’t have to rely on an external task list. You 
can do this by defining an example without a block: 

# spec/models/customer_spec . rb 146 


require ' spec_helper ' 
describe Customer do 

it "should create a new instance given valid attributes" do 
Customer . create !(: name => 'John', active: false) 
end 

pending "should set the record as active on create" 

describe "when destroyed" do 

pending "should not delete the record from the database" 
pending "should set the customer as inactive" 
end 
end 


# spec/control lers/customers_control ler_spec . rb 147 


146 https://github.com/bryanbibat/rasm40code/commit/05ad7332ee9b6dd54ccde57516da67c986443522#diff-l 

147 https://github.com/bryanbibat/rasm40code/commit/05ad7332ee9b6dd54ccde57516da67c986443522#diff-0 
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let( : val id_attributes) { { "name" => "MyString", "active" => true 


describe "GET index" do 

it "assigns all customers as ©customers" do 
customer = Customer . create ! val id_attributes 
get : index, {}, val id_session 
assigns( : customers) .should eq( [customer] ) 
end 

pending "should only retrieve active customers" 
end 

describe "GET show" do 

describe "when the record is active" do 

it "assigns the requested customer as ©customer" do 
customer = Customer . create ! val id_attr ibutes 
get :show, { : id => customer . to_param} , val id_session 
assigns( : customer) .should eq(customer) 

end 

end 

describe "when the record is inactive" do 
pending "redirects to the list" 
pending "displays a message" 
end 
end 


# spec/views/customers/index . html . erb_spec . rb 148 


it "renders a list of customers" do 
render 

response . should have_selector( "tr>td" , : content => "Name".to_s 
response . should have_selector( "tr>td" , : content => false. to_s, 
end 

pending "does not display the Active field" 
end 

Running rake spec would produce: 


:count => 2) 
:count => 2) 


148 https://github.com/bryanbibat/rasm40code/commit/05ad7332ee9b6dd54ccde57516da67c986443522#diff-2 
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Pending : 

CustomersControl ler GET index should only retrieve active customers 

# No reason given 

# . /spec/control lers/customers_control ler_spec . rb : 40 

CustomersControl ler GET show when the record is inactive redirects to the list 

# No reason given 

# . /spec/control lers/customers_control ler_spec . rb : 52 
CustomersControl ler GET show when the record is inactive displays a message 

# No reason given 

# . /spec/control lers/customers_control ler_spec . rb : 53 
Customer should set the record as active on create 

# No reason given 

# . /spec/models/customer_spec . rb : 8 

Customer when destroyed should not delete the record from the database 

# No reason given 

# . /spec/models/customer_spec . rb : 11 

Customer when destroyed should set the customer as inactive 

# No reason given 

# . /spec/models/customer_spec . rb : 12 
customers/ index does not display the Active field 

# No reason given 

# . /spec/views/customers/index . html . erb_spec . rb : 23 

Finished in 0.35098 seconds 
38 examples, 0 failures, 7 pending 

Red - Green - Refactor 


The most basic of ideas in TDD is the concept of “Red - Green - Refactor”. When performing TDD, you 
will have go through continuous cycles of these three stages. 

Red is the first stage, wherein you write a failing test. This is important: your test must first fail before 
your could proceed to the next stage. If it doesn’t fail, it means it isn’t testing anything and, as such, a 
useless test. 

Green is the second stage, wherein you write the minimum amount of code that would make the test 
pass. This lets you focus on the feature you are writing and preventing you from “gold-plating” your code 
with unnecessary features. Whenever you’re tempted to add code because you think that you are going 
to need it in the future, just rememberi YAGNI: you ain’t gonna need it. 

Third stage is refactor, wherein you clean up your code if needed. Refactoring is a lot safer here thanks 
to the tests in place. After refactoring, you proceed to the next feature and do Red - Green - Refactor all 
over again. 

Let’s do this in our first feature, setting the default value of active to true. First let’s add a failing test 149 : 


149 https://github.com/bryanbibat/rasm40code/commit/8b34c785b8f40fbeca54f5b4a3def3cffd57fbb0#diff-l 
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it "should set the record as active on create" do 

customer = Customer . create(name : "name", active: false) 
customer . reload 

customer active . should eq true 
end 


After running rake spec, we now get our “red”: 

* _ P** _ * _ ** 

Fai lures : 

1) Customer should set the record as active on create 
Failure/Error: customer . active . should eq true 
expected true 
got false 

(compared using ==) 

* . /spec/models/customer_spec . rb : 11 : in 'block (2 levels) in <top (required))' 
Finished in 0.88928 seconds 
37 examples, 1 failure, 6 pending 


Predicates 

Before we proceed with coding the correct code, note that RSpec provides a special method when testing 
boolean methods: the predicate matchers. For example: 

customer . should be_active 

would perform the same checking, but with a much human-readable syntax and error message: 

1) Customer should set the record as active on create 
Failure/Error: customer . should be_active 
expected active? to return true, got false 
* . /spec/models/customer_spec . rb : 11 : in 'block (2 levels) in <top (required)) 1 

With predicate matchers, all boolean methods can be tested using be_[ method] with method being a 
boolean method that ends with More information on predicates can be found at the API docs under 
Matchers. 

Going to Green 

Back to the TDD walkthrough, turning the red into green should be easy with callbacks 150 : 


15 °https://github.com/bryanbibat/rasm40code/commit/8b34c785b8f40fbeca54f5b4a3def3cffd57fbb0#diff-0 
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class Customer < Act i veRecord :: Base 

before_create : activate 
private 

def activate 

self, active = true 
end 

end 

Running rake spec should now give us green (and yellow): 

Finished in 0.329416 seconds 
37 examples, 0 failures, 6 pending 

Now to the next feature 151 : 

describe "when destroyed" do 

fixtures customers 

it "should not delete the record from the database" do 
customer = customers( : active) 
customer destroy 

customer , should_not be_destroyed 
end 

pending "should set the customer as inactive" 

end 

Fixtures 

Before we can get the spec to work, we must first understand what fixtures are. 

Fixtures are basically test data stored in a file. In the case of RSpec, these are YAML 152 files stored 
in the spec/f ixtures/ folder. By calling fixtures : customers, we tell RSpec to load the fixtures in 
the spec/f ixtures/customers . yml file into the test database. Then we can access these records via the 
customers ( : key) call, where :key is the identifier for the record in the YAML file. 

Create the file spec/f ixtures/customers. yml 153 with: 


151 https://github.com/bryanbibat/rasm40code/commit/45824dad936da32049b6a35c578ba2bb57ece86b#diff-l 
1 5 2 http ://en. wikipedia. org/ wiki/ Y AML 

153 https://github.com/bryanbibat/rasm40code/commit/45824dad936da32049b6a35c578ba2bb57ece86b#diff-0 
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active : 

name: Active Customer 
active: true 
inactive : 

name: Inactive Customer 
active: false 

This loads two records in the database, one can be referred as customers ( : act i ve ) , the other customer s ( : i nact i ve ) . 

However, RSpec loads all fixtures in all examples by default. Since this will affect many of our other tests, 
let’s disable that in spec_helper .rb 154 for this tutorial: 

RSpec . configure do Iconfigl 

config. order - "random" 

config global_f ixtures = [] 
end 

Back to our example, we retrieved the customer record, called destroy, and expected it not to be destroyed. 

As expected, this would make the specs fail: 

1) Customer when destroyed should not delete the record from the database 
Failure/Error: customer . should_not be_destroyed 
expected destroyed? to return false, got true 
# . /spec/models/customer_spec . rb : 20 : in 'block (3 levels) in <top (required))' 

Finished in 0.91271 seconds 
37 examples, 1 failure, 5 pending 

Minimum Code 

Here’s what we need to add to the model to make the spec pass 155 : 

class Customer < Act i veRecord :: Base 
be f ore_cr eate : act i vate 

def destroy 
end 

private 

def activate 

self. active = true 
end 

end 

154 https://github.com/bryanbibat/rasm40code/commit/45824dad936da32049b6a35c578ba2bb57ece86b#diff-2 

155 https://github.com/bryanbibat/rasm40code/commit/312be620ff47f89c5dbfc0de71cefab06bfe9691 
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Yes, simply overriding the destroy method without doing anything else looks weird. But recall what we 
said before: write the minimum amount of code that would make the test pass. This is the correct approach 
for the failing example, leaving the “proper” code to the other pending example. 

Running rake spec will give us: 

Fai lures : 

1) CustomersControl ler DELETE destroy destroys the requested customer 
Failure/Error: expect { 

count should have been changed by -1, but was changed by 0 
* . /spec/control lers/customers_control ler_spec . rb : 156 : in 'block (3 levels)... 

Finished in 0.44933 seconds 
38 examples, 1 failure, 5 pending 

The change produced an error in our controller test for DELETE which expected the number of results 
to go down by one. We’ll fix this problem later; for now we’ll work on the rest of the model specs 156 and 
code: 


it "should set the customer as inactive" do 

customer = customers( : active) 
customer destroy 
customer should_not be_active 
end 


rake spec (red): 


Fai lures : 

1) CustomersControl ler DELETE destroy destroys the requested customer 
Failure/Error: expect { 

count should have been changed by -1, but was changed by 0 

# . /spec/control lers/customers_control ler_spec . rb : 156 : in 'block (3 levels)... 

2) Customer when destroyed should set the customer as inactive 
Failure/Error: customer . should_not be_active 

expected active? to return false, got true 

# . /spec/models/customer_spec . rb : 25 : in 'block (3 levels) in <top (required)) 1 

Finished in 0.39228 seconds 
38 examples, 2 failures, 4 pending 

Actual code 157 : 


156 https://github.com/bryanbibat/rasm40code/commit/9553f3ae3559562e378blf5debcc8cle6874a52f#diff-l 

157 https://github.com/bryanbibat/rasm40code/commit/9553f3ae3559562e378blf5debcc8cle6874a52f#diff-0 
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class Customer < Act i veRecord :: Base 
before_create : activate 

def destroy 

self. active = false 
self . save 
end 

private 

def activate 

self. active = true 
end 

end 

rake spec (green): 

Fai lures : 

1) CustomersControl ler DELETE destroy destroys the requested customer 
Failure/Error: expect { 

count should have been changed by -1, but was changed by 0 
# . /spec/control lers/customers_control ler_spec . rb : 156 : in 'block (3 levels)... 

Finished in 0.36941 seconds 
38 examples, 1 failure, 4 pending 

At this point, we can do some refactoring. Not on our code, though, but on our examples 158 : 

describe "when destroyed" do 
fixtures : customers 

before( : each) do 

©customer = customers( : active) 

©customer destroy 
end 

it "should not delete the record from the database" do 
©customer should_not be_destroyed 
end 

it "should set the customer as inactive" do 
©customer should_not be_active 
end 
end 

We refactored the retrieve and destroy to the setup method. Running rake spec here would still produce 
green. 


158 https://github.com/bryanbibat/rasm40code/commit/62ed25373aa784ba829671fbf2a891e23f600f5f 
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Quick Walkthrough of the Rest of the Features 

We won’t be introducing anything new so the next pages will just be a walkthrough of the remaining 
features to be coded. 

Spec 159 : 


it "should only retrieve active customers" do 
customer = Customer . create ! val id_attr ibutes 
customer destroy 
get : index, {}, val id_session 
assigns( :customers) .should eq( [] ) 
end 


rake spec (red): 

Finished in 0.42289 seconds 
38 examples, 2 failures, 3 pending 

Actual code 160 : 

class Customer < Act i veRecord :: Base 
default_scope { where(active: true) } 

before_create : activate 


rake spec (finally green for all): 

Pending : 

CustomersControl ler GET show when the record is inactive redirects to the list 

# No reason given 

# . /spec/control lers/customers_control ler_spec . rb : 57 
CustomersControl ler GET show when the record is inactive displays a message 

# No reason given 

# . /spec/control lers/customers_control ler_spec . rb : 58 
customers/ index does not display the Active field 

# No reason given 

# . /spec/views/customers/index . html . erb_spec . rb : 23 

Finished in 0.42319 seconds 
38 examples, 0 failures, 3 pending 

New Spec 161 : 


159 https://github.com/bryanbibat/rasm40code/commit/97425e6792fd892e7b030cf4fbc26bf586ce2693#diff-l 

160 https://github.com/bryanbibat/rasm40code/commit/97425e6792fd892e7b030cf4fbc26bf586ce2693#diff-0 

161 https://github.com/bryanbibat/rasm40code/commit/6633d946ae23020efb319e426bec2b5a2f46afl6#diff-l 
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describe "when the record is inactive" do 
it "redirects to the list" do 

customer = Customer . create ! val id_attributes 
customer destroy 

get :show, { : i d => customer . to_param} , val id_session 
response . should redirect_to(customers_url ) 

end 

pending "displays a message" 

end 


rake spec (red): 

1) CustomersControl ler GET show when the record is inactive redirects to the list 
Failure/Error: get :show, { : id => customer . to_param) , val id_session 
ActiveRecord : : RecordNotFound : 

Couldn't find Customer with id=l [WHERE "customers" . "active" = ' t ' ] 

* . /app/control lers/customers_control ler . rb : 67 : in 'set_customer ' 

# . /spec/control lers/customers_control ler_spec . rb : 60 : in 'block (4 levels) in 
<top (required)> ' 

Finished in 0.96183 seconds 
37 examples, 1 failure, 2 pending 

Actual code 162 : 


def show 

if @customer . active? 
respond_to do | format I 
format . html 
format . json 
end 
else 

respond_to do | format I 

format.html { redirect_to customers_url 
format. json { render status: :not_found 
end 
end 
end 


} 

} 


def set_customer 

^customer = Customer . unscoped f ind(params [ : id] ) 
end 


rake spec (green): 


162 https://github.com/bryanbibat/rasm40code/commit/6633d946ae23020efb319e426bec2b5a2f46afl6#diff-0 
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* * 


Finished in 0.348318 seconds 
38 examples, 0 failures, 2 pending 


Spec 163 : 


it "displays a message" do 

customer = Customer . create ! val id_attributes 
customer destroy 

get :show, { : i d => customer . to_param} , val id_session 
flash [: notice] . should eq "Record does not exist" 

end 


rake spec (red): 

1) CustomersControl ler GET show when the record is inactive displays a message 
Failure/Error: flash [: notice] . should eq "Record does not exist" 

expected "Record does not exist" 
got nil 

(compared using ==) 

* . /spec/control lers/customers_control ler_spec . rb : 44 : in 'block (4 levels) in 
<top (required)> ' 

Finished in 0.95122 seconds 
38 examples, 1 failure, 1 pending 

Actual code 164 : 

def show 

else 

respond_to do I format | 

format.html { redirect_to customers_url , notice: "Record does not exist" } 

format. json { render status: :not_found } 

end 

end 

end 

rake spec (green): 


163 https://github.com/bryanbibat/rasm40code/commit/2294d07c79981edleelld8a71421bc35defb2ad2#diff-l 

164 https://github.com/bryanbibat/rasm40code/commit/2294d07c79981edleelld8a71421bc35defb2ad2#diff-0 
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* 


Pending : 

customers/ index . html . erb does not display the Active field 

# no reason given 

# . /spec/views/customers/index . html . erb_spec . rb : 23 

Finished in 0.96966 seconds 
38 examples, 0 failures, i pending 

Last spec 165 : 


it "does not display the Active field" do 
render 

rendered . should_not have_selector ( "tr>th" , : content => "Active") 

rendered . should_not have_selector ( "tr >td" , :content => false. to_s, :count => 2) 

end 


rake spec (red): 

1) customers/ index . html . erb does not display the Active field 

Failure/Error: rendered . should_not have_selector( "tr>th" , : content => "Active") 
expected following output to omit a <tr>th>Active</tr>th> : 

* . /spec/views/customers/index . html . erb_spec . rb : 25 : in 'block (2 levels) in <top 
(required)> ' 

Finished in 0.969 seconds 
38 examples, 1 failure 

Actual code 166 (remove the active related lines): 

<table> 

<tr> 

<th>Name</th> 

<th>Activc</th> 

</tr > 

<% ©customers . each do I customer I %> 

<tr> 

<tA> <%= customer . name X></td> 

<td>'A~ customer . active /></td> 

<td><%= link_to 'Show', customer X></td> 


rake spec (still red): 


165 https://github.com/bryanbibat/rasm40code/commit/e4c51a21df5b9fb0bldl5d620d502cl89e5e3fe2#diff-l 

166 https://github.com/bryanbibat/rasm40code/commit/e4c51a21df5b9fb0bldl5d620d502cl89e5e3fe2#diff-0 
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1) customers/ index . html . erb renders a list of customers 

Failure/Error: rendered . should have_selector( "tr>td" , : content => false. to_s, 
:count => 2) 

expected following output to contain a <tr>td> false</tr>td> tag: 

# . /spec/views/customers/index . html . erb_spec . rb : 20 : in 'block (2 levels) in <top 
(required) > ' 

Finished in 0.98027 seconds 
37 examples, 1 failure 

Fixing the broken spec 167 : 

it "renders a list of customers" do 
render 

rendered should have_tag( "tr>td" , "Name" to_s, : count => 2) 

rendered . should havc_tag( "tr>td" , — false . to_s, — : count = — 2-)- 

end 

rake spec (green): 


Finished in 0.46764 seconds 
38 examples, 0 failures 

The Last Step 

One of the biggest advantages of doing TDD is that you don’t need to use the browser when testing your 
program. One of the biggest disadvantages of doing TDD is that you don’t use the browser when testing 
your program. 

As has been stated at the beginning of this chapter, automated testing is not meant to replace manual 
testing. You must still somehow test your program after you code it; maybe you’ll discover incorrect test 
cases, or maybe you’ll find out that you missed some test cases. Putting too much trust on your unit tests 
can be a recipe for disaster. 

As a “homework” for the reader, there is at least 1 critical bug in the code above. It is up to you to find 
it then create the necessary specs before fixing it. 


167 https://github.com/bryanbibat/rasm40code/commit/096d220fd389264b4b68117cef39a2d9955e9439 
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More about Automated Testing 

We’ve only scratched the surface of the large and complicated world of automated testing. Here are some 
topics that could answer the question “where should I go next?” 

Integration Testing 

Yet another term that puts developers at odds with the QA people, “integration testing”, in the context of 
automated testing, simply means a full end-to-end testing of a feature, with the model, view, and controller 
working together as they should in the real world. 

There are different ways of performing integration testing. The first would be through simulating the 
browser. The de facto BDD integration testing tool for Rails, Cucumber, uses this approach with the help 
of the Webrat library. 

Another approach would be to have a tool that records actions from a browser, and then replays the 
actions again later to test if it produces the expected behavior. Selenium, another testing framework, uses 
this approach. 

Integration tests allow you to automate the testing of features at the User Story level. The drawback here 
is that integration tests are far slower than their “unit” testing counterparts. Because of this, integration 
tests are often paired with unit tests; developers run the unit tests while going through the red - green - 
refactor phase, then they run the integration tests only when they push their changes to the build. 

TDD vs BDD 

Test Driven Development is a bottom-up approach to development. Before we code a method, we write 
a test for it. From there we build up our program, writing tests along the way. The flow goes something 
like this: 



Behavior Driven Development, on the other hand, is a top-down approach. We start by translating the 
user requirements as an integration test, then we go down to the view to translate the UI requirements 
to view specs, and so on. This way, we have the user requirements at the forefront of the specs instead of 
the program’s low-level implementation details. 
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As for which is better, BDD is certainly more pragmatic than TDD. However, being the predecessor, TDD 
is more widely used than BDD. 

Then there’s the question of whether to do as the purists do and test everything, or be even more pragmatic 
and just code what’s needed. People in the latter camp mostly use integration tests and only code the most 
complicated controller and model specs. 

Regardless of what camp you fall in, TDD or BDD, full test coverage or just testing features, one thing is 
clear: any (proper) automated testing is better than no testing at all. 


Deployment 

This final chapter deals with the various issues and concerns behind deploying your applications. 

Configuration 

Convention over Configuration means that, in Rails, we don’t have to configure most of the settings that 
need to be configured in a typical web application. However, we still need to configure some settings, 
especially those settings that change depending on the environment where the application is deployed to 
or executed. 

Rails Settings 

You can find the global configuration settings for your Rails application at con f i g/app 1 i cat i on . r b. Here’s 
the default configuration file when you create an application: 

require File.expand_path( ' . ./boot' , FILE ) 

require 'rails/all ' 

* Require the gems listed in Gemfile, including any gems 

# you've limited to :test, : development, or '.production. 

Bundler . require(*Rai Is . groups) 

module AlingnenaApp 

class Application < Rai Is : : Appl ication 

# Settings in con fig/environments/* take precedence over those specified here. 

# Application configuration should go into files in con fig/initializers 

# -- all .rb files in that directory are automatical ly loaded. 

# Set Time . zone default to the specified zone and make Active Record auto-. . . 

# Run "rake -D time" for a list of tasks for finding time zone names. Default. . . 

# con fig ,time_zone = 'Central Time (US & Canada)' 

# The default locale is :en and all translations from con fig/locales/* . rb, yml .. . 

# con fig . H8n . load _path += Dir [Rails .root . join( ' my ' , 'locales', ' * . {rb, yml } ' ) . . . 

# config . H8n . default_locale = :de 

end 

end 

The first few lines simply loads all of the available packages before running Rails. Here we see how Rails 
loads the gems defined in Gemfile via Bundler. 

The bulk of the file contains global configuration settings. You might remember config.time_zone that 
we already discussed back in the Active Support lesson. 
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Environment specific settings exist in our applications. For example, verbose debugging errors may not be 
as useful in production as it is in development so we set it in the latter and disable it in the former. We can 
set environment specific settings inside the con fig/environments folder. By default, a Rails application 
has 3 environments: 

• development - the default environment, built for development. This is the environment where 
we’ve been working on before we went to testing 

• test - this is the environment where our tests are executed against 

• production - the environment that the users will eventually use 

Each of these environments have a . rb file in the conf ig/environments folder containing their settings 
i.e. development . rb, test . rb, and production . rb. 

Looking at development and production, we could see some significant differences. Here’s the default 
development . rb contents: 


AlingnenaApp : Application configure do 

* Settings specified here will take precedence over those in config/application.rb. 

* In the development environment your application's code is reloaded on 

* every request. This slows down response time but is perfect for development 

* since you don't have to restart the web server when you make code changes. 
conf ig . cache_classes = false 

* Do not eager load code on boot. 

conf ig . eager_load = false 

* Show full error reports and disable caching. 

conf ig . cons ider_al l_requests_local = true 

conf ig . action_control ler perform_caching = false 

* Don't care if the mailer can't send. 

conf ig . act ion_mai ler . raise_del ivery_errors = false 

* Print deprecation notices to the Rails logger. 

conf ig . active_support deprecation : log 

* Raise an error on page load if there are pending migrations 
conf ig . active_record . migration_error = :page_load 

* Debug mode disables concatenation and preprocessing of assets. 

* This option may cause significant delays in view rendering with a large 

* number of complex assets. 
conf ig . assets debug = true 

end 


while here is production . rb: 
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AlingnenaApp : Appl ication . configure do 

* Settings specified here will take precedence over those in con fig/application . rb . 

* Code is not reloaded between requests. 

conf ig . cache_classes = true 

* Eager load code on boot. This eager loads most of Rails and 

* your application in memory, allowing both thread web servers 

* and those relying on copy on write to perform better. 

* Rake tasks automatically ignore this option for performance. 
conf ig . eager_load = true 

* Full error reports are disabled and caching is turned on. 

conf ig . cons ider_al l_requests_local = false 

conf ig . action_control ler perform_caching = true 

* Enable Rack: : Cache to put a simple HTTP cache in front of your application 

* Add 'rack-cache' to your Gemfile before enabling this. 

* For large-scale production use, consider using a caching reverse proxy like... 

* config.action_dispatch.rack_cache = true 

* Disable Rails's static asset server (Apache or nginx will already do this). 

conf ig . serve_static_assets = false 

* Compress JavaScripts and CSS. 

conf ig . assets . js_compressor = :uglifier 

* con fig . assets . css_compressor = :sass 

* Do not fallback to assets pipeline if a precompiled asset is missed. 

conf ig . assets . compi le = false 

* Generate digests for assets URLs. 
conf ig. assets digest = true 


# Version of your assets, change this if you want to expire all your assets. 
conf ig . assets . version = '1.0' 


* Specifies the header that your server uses 

* config.action_dispatch.x_sendfile_header = 

* config.action_dispatch.x_sendfile_header = 


for sending files. 

"X-Sendfile" # for apache 
' X-Accel -Redirect ' # for nginx 


# Force all access to the app over SSL, use Strict-Transport-Security, and use... 

* config.force_ssl = true 


# Set to : debug to see everything in the log. 
conf ig . log_level = : info 


* Prepend all log lines with the following tags. 

* config.log_tags = [ : subdomain , :uuid ] 


Deployment 


184 


* Use a different logger for distributed setups. 

* con fig . logger = ActiveSupport : : TaggedLogging . new(SyslogLogger . new) 

* Use a different cache store in production . 

* con fig ,cache_store = : mem_cache_store 

* Enable serving of images , stylesheets, and JavaScripts from an asset server. 

* config . action_control ler . asset_host = "http://assets.example.com" 

* Precompile additional assets. 

* application . js, application. css, and all non-JS/CSS in app/assets folder are... 

* con fig . assets . precompile += %\n( search . js ) 

* Ignore bad email addresses and do not raise email delivery errors. 

* Set this to true and configure the email server for immediate delivery to raise... 

* config . action_mai ler . raise_del ivery_errors = false 

* Enable locale fallbacks for I18n (makes lookups for any locale fall back to 

* the I18n . default_locale when a translation can not be found). 

config . il8n . fal lbacks = true 

* Send deprecation notices to registered listeners. 

config . active_support deprecation : notify 

* Disable automatic flushing of the log to improve performance . 

* con fig . auto flush_log = false 

* Use default logging formatter so that PID and timestamp are not suppressed . 

config . log_formatter = :: Logger :: Formatter . new 

end 

We can see here why we don’t need to restart the server every time we make a change to our application; 
in development, the classes and templates are not cached. On the other hand, in production, all classes 
and templates are cached to improve performance. 

Configuration settings for internationalization (il8n) will be discussed in the Internationalization section 
below. Other configuration settings can be found at the API docs under Rails: Application. 

Database Settings 

We already discussed in the previous chapter where the database settings are located: conf ig/database . yml . 
Here’s a sample from an SQLite based application: 
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* SQLite version 3.x 

* gem install sqlite3 
development : 

adapter: sqlite3 

database: db/development . sql ite3 
pool : 5 
timeout: 5000 

* Warning: The database defined as "test" will be erased and 

* re-generated from your development database when you run "rake". 

* Do not set this db to the same as development or production . 

Test : 

adapter: sqlite3 
database: db/test . sql ite3 
pool : 5 
timeout: 5000 

production : 

adapter: sqlite3 
database: db/production . sql ite3 
pool : 5 
timeout: 5000 

And here’s one from a MySQL based application (rails new app_name -d mysql): 

* MySQL. Versions 4.1 and 5.0 are recommended . 

* 

# Install the MySQL driver: 

# gem install mysql2 

# 

* And be sure to use new-style password hashing: 

* http : //dev . mysql . com/doc/re f man/5 . 0/en/old-cl ient . html 

development : 

adapter: mysql 2 
encoding: utf8 
reconnect: false 
database: mysql_development 
pool : 5 

username: root 
password : 
host: localhost 

* Warning: The database defined as "test" will be erased and 

* re-generated from your development database when you run "rake" . 

* Do not set this db to the same as development or production . 
test : 

adapter: mysql 2 
encoding: utf8 
reconnect : false 
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database: mysql_test 
pool : 5 

username: root 
password : 
host: localhost 

production : 

adapter: mysql2 
encoding: utf8 
reconnect: false 
database: mysql_production 
pool : 5 

username: root 
password : 
host: localhost 

Like in our configuration files, the three default environments are also defined in database . yml, each as 
a YAML entry. 

Each environment entry in database . yml must at least have an adapter and database value. All the other 
values are database specific. You can refer to Rails wiki on database support 168 for the latest information 
on installing adapters for different databases as well as the properdatabase.yml settings for those adapters. 
For example, here’s a possible entry for MS SQL Server: 

development : 

adapter : sq 1 server 
mode : ODBC 

dsn: YOUR_DB_DEF INI T ION _NAME 
username : YOUR_DB_USERNAME 
password : YOUR_DB_PASSWORD 

You can actually define different databases for each environment, say, SQLite for development, MySQL for 
testing, and Oracle for production. This is discouraged, however, as the inconsistencies between database 
implementations might create bugs that won’t be detected in development or testing. 

Internationalization 

Rails provides support for translating text and localizing time through its internationalization (il8n) 
library. We’ve already seen the basic settings for this module in conf ig/environment . rb: 

* The default locale is :en and all translations from con fig/locales/* . rb, yml are... 

* config.H8n.load_path += Dir [Rails .root . join( ' my ' , 'locales', ' * . [rb, yml } ' ) . to_s] 

* config.H8n.default_locale = : de 

The first commented setting provides an example of how to add an additional translation path for the 
translation files. In this case, all *.rb and *.yml files from the my/locales folder are loaded along with 
the files from conf ig/locales/ folder. 


168 http://wiki.mbyonrails.org/start#database_support 
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The second commented setting is an example of how to set the default locale for the application, in this 
case, German. 

There are many ways for setting the user’s locale. The simplest would be to have a filter in App 1 i cat ionContro 1 1 er 
that checks for a locale parameter and assigns it to I18n . locale 169 : 

before_action :set_locale 

private 

def set_locale 

I18n. locale = params [: locale] 

end 

Once this is set, going to any page with the locale parameter, say http : //localhost : 3000/products?locale=de , 
would render a page using the provided locale. 

Now that we’ve set up locale handling, let’s move on with the actual internationalization of our 
application. There are two basic helpers for il8n: 

• t - alias of translate. Looks up text from the translation files 

• 1 - alias of localize. Localizes date and time to local formats 

We use these helpers to translate text and localize time in cases where Rails doesn’t do the translation 
and localization for us. For example, field labels and form error messages are automatically translated, 
but flash messages are not. 

Let’s start with a simple example, applying il8n to our New Product page 170 . 

<M><%=t ' views . product . header . new ' %></hl> 

<%- render "form", product: ©product, button_label : t( ' views . button . create ' ) %> 

<%= link_to t( ' views . 1 ink . back ') , products_path %> 


Opening http : //localhost : 3000/products/new would result in: 


169 https://github.com/bryanbibat/rasm40code/commit/7385b4cfbe57cdcl089fdl9d94da21f8bf6c03e0#diff-0 

17o https://github.com/bryanbibat/rasm40code/commit/7385b4cfbe57cdcl089fdl9d94da21f8bf6c03e0#diff-l 
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11 

imroi 

ZA 




© localhost: 3000/products/new & 

" 


en, views, product, header, new 


Name 


Description 


Cost 


Stock 


<span class= en. views, button, create" /> 

en. views, link, back 


We’re missing translations for views . product . header . new, views . button . create, and views .link. back. 

Let’s add these to English translation file at conf ig/locales/en . yml 171 : 

en : 

hello: "Hello world" 

views : 
button : 

create: "Create" 
link: 

back: "Back" 
product : 
header : 

new: "New Product" 

The translation should now work: 


171 https://github.com/bryanbibat/rasm40code/commit/7385b4cfbe57cdcl089fdl9d94da21f8bf6c03e0#diff-2 
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- n 


yg AlingnenaApp 

^ 


C © localhost:3000/products/new& ^ 


New Product 

Name 


Description 


Cost 


Stock 


Create 


Back 


Let’s try translating the page to Tagalog. Create a new translation file conf ig/locales/tl .yml 
tl : 

views : 
button : 

create: "Likhain" 
link: 

back: "Bumalik" 
product : 
header : 

new: "Bagong Produkto" 


Restart the server then go to http : //local host : 3000/products/new?locale=tl: 


172 . 


172 https://github.com/bryanbibat/rasm40code/commit/b4f6ceb937e31e53e99f8ae82ba539b955bfe75e 
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We’re still missing the translations for the fields (let’s ignore the title bar). To translate them, we’re going 
to need to add entries for Active Record 173 : 

tl : 

views : 
button : 

create: "Likhain" 

1 ink : 

back: "Bumalik" 
product : 
header : 

new: "Bagong Produkto" 
activerecord : 
models : 

product: "Produkto" 
attributes : 
product : 

name: "Pangalan" 
description: "Paglalarawan" 
cost: "Presyo" 
stock: "Dami" 

the activerecord entry allows us to set the name of the model as well as its attributes/fields. 


173 https://github.com/bryanbibat/rasm40code/commit/7f776a58fl8ef52642ac39637438a78a9627ca5f 
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: — n 


AtingnenaApp 

Egfflfv + 


^ ^ C O localhost:3000/products/new?locale=tl & \ 


Bagong Produkto 

Pangalan 

I 

Paglalarawan 


Presyo 


Dami 


Likhain 


Bumalik 


It looks ok, but if you store the locale into the session in our filter like so 174 : 
def set_locale 

I18n locale params [: locale] II session [: locale] 

session [: locale] = params [: locale] if params . has_key? : locale 

end 

and save a blank product, you’ll see that we’re missing translations for our errors. 

174 https://github.com/bryanbibat/rasm40code/commit/1400e6497dafabl8f247038c4ea4blfaf86d375b 
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— n 


AlingnenaApp 

+ 


^ . 0 © localhost:3000/products 


☆ * 


Bagong Produkto 


2 errors prohibited this product from being saved: 


• Pangalan translation missing: 
tl.activerecord.errors.models.product.attributes.name. blank 

• Paglalarawan translation missing: 

tl. active record. errors. models. product.attributes. description. blank 


First off, we need to internationalize our error header. This can be done by modifying the line in 
app/views/products/_form . html .erb 175 to: 


<% if product . errors . any? %> 

<div id="error_explanation" > 

<h2 > <%= t "activerecord . errors . template . header" , count: product errors count, 
model: product .class model_name human . downcase X>:</h2> 

<ul> 

And we need to add the following line to conf ig/locales/en .yml 176 : 
en : 

activerecord : 
errors : 
template : 
header : 

one: "1 error prohibited this %{model} from being saved" 

other: "%{count} errors prohibited this %{model} from being saved" 

Here we see two il8n features: pluralization and interpolation. 

The pluralization part only requires you to define two translations: one to format the singular message, 
another to format the plural message. You then pass the : count option to determine if the message is 
plural or not. 

The interpolation feature allows you to interpolate variables inside the messages. You pass these variables 
as options to t( ) (: count included) and the method inserts them to sections defined by “%{}”. 

175 https://github.com/bryanbibat/rasm40code/commit/986e256a9dblalf4ca477elafdlec0331cb0e557#diff-0 

17s https://github.com/bryanbibat/rasm40code/commit/986e256a9dblalf4ca477elafdlec0331cb0e557#diff-l 
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Now we are done discussing the header, lets move on to the field errors. Fortunately, they have namespaces 
to allow you to define the error messages in generic or specific ways. 

For example, validates : presence uses the : blank error message. You can define this error message 
under: 


activerecord . errors . models . [model_name] .attributes. [attr ibute_name] .blank 
activerecord . errors . models . [model_name] .blank 
activerecord . errors . messages . blank 

That is, Rails will first check if the error message is defined for the specific attribute, then it would check 
the model, then it would check if a generic message was defined. 

Rails il8n provides three values which you can interpolate with your messages, model (the model name), 
attribute (the field name), and count. For example, our blank message in Tagalog would be: 

blank: "Dapat ipuno ang %{attribute} " 


The count value is only available for some messages. Flere is a list of the default error messages in Rails: 


validation 

with option 

message 

default message 

: confirmation 


: confirmation 

doesn’t match 
confirmation 

: acceptance 


: accepted 

must be accepted 

: presence 


: blank 

can’t be blank 

: length 

: within, : in 

: too_short 

is too short (minimum is 
%{count) characters) 

: length 

: within, : in 

: too_long 

is too long (maximum is 
%{count) characters) 

: length 

: is 

: wrong_length 

is the wrong length 
(should be %{count) 
characters) 

: length 

:minimum 

: too_short 

is too short (minimum is 
%{count) characters) 

: length 

: maximum 

: too_long 

is too long (maximum is 
%{count) characters) 

: uniqueness 


: taken 

has already been taken 

: format 


: inval id 

is invalid 

: inclusion 


: inclusion 

is not included in the list 

: exclusion 


: exclusion 

is reserved 

val idates_associated 


: inval id 

is invalid 

: numerical ity 

: not_a_number 

: not_a_number 

is not a number 

: numerical ity 

: greater_than 

: greater_than 

must be greater than 
%{count) 

: numerical ity 

: greater_than_or_- 

: greater_than_or_- 

must be greater than or 


equal_to 

equal_to 

equal to %(count) 

: numerical ity 

: equal_to 

: equal_to 

must be equal to %{count) 

: numerical ity 

: less_than 

: less_than 

must be less than %{count) 

: numerical ity 

: less_than_or_equal_to 

: less_than_or_equal_to 

must be less than or equal 
to %{count) 

: numerical ity 

: odd 

: odd 

must be odd 

: numerical ity 

: even 

: even 

must be even 
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Our updated tl . yml 177 file would be: 


stock: "Dami" 

errors : 
template : 
header : 

one: "May isang mali na humahadlang sa pag-save ng %{model}" 

other: "May %{count} mali na humahadlang sa pag-save ng %{model}" 
messages : 

blank: "Dapat ipuno ang %{attribute} " 


There’s still one problem with our error message: 


li 

1 [Z] r n 1 


_ 

j AlingnenaApp 


| ^ ^ C © localhost: 3000/products & 



Bagong Produkto 





By default, the full error message is in the form “%{attribute} %{message}”. We can change that format by 
through the tl . errors . format 178 entry: 


tl : 


errors : 

format: "%{message}" 

Now our final message would be: 

177 https://github.com/bryanbibat/rasm40code/commit/ec68fl2838fd95563763f99b740e7abdf07c5636 

178 https://github.com/bryanbibat/rasm40code/commit/5549f92e0f2lbcad8686dc0fcad8c6b98c97179c 
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To demonstrate the time localization, let’s modify Show Product to add the created_at field along with 
the other il8n changes 179 : 

<hi><%=t "views . product . header . show" %></hi> 

<P> 

<strong><£= label (: product, :name) %> : </strong> 

<%= ©product . name %> 

</p> 

<p> 

<strong><£= label (: product, : description) %> : </strong> 

<%= ©product . description %> 

</p> 

<p> 

<strong><^= label (: product, :cost) %> : </strong> 

<%= number_to_currency @product . cost, unit: "PhP" %> 

</p> 

<P> 

<strong><^= label (: product, : stock) Z> : </strong> 

<%= number_with_del i imiter ©product . stock %> 

</p> 

<p> 

<strong><^= label (: product, :created_at) %> : </strong> 

<%=1 ©product . created_at %> 

</p> 

Going to http://localhost:3000/products/3?locale=en will give us (assuming 3 is the id of the Cola 
entry): 


175 https://github.com/bryanbibat/rasm40code/commit/c732df8eel48dlcbb27b24ada711b0e08757bec5 
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nmroi 


AlingnenaApp 



C © localhost:3000/products/3?locale=en & \ 


en, views, product, header, show 

Name: Cola 
Description: fizzy drink 
Cost: PhP 25.00 
Stock: 100 

Created at: Thu. 24 Feb 2011 18:36:37 +0000 




But trying http : //localhost : 3000/products/3?locale=tl will give us an error: 



c © localhost:3000/products/3?locale=tl ^ ^ 


I18n;: Missing! 
Products#sno 


TransiationData in 
w 


Showing /home/bry/branck/alingnena- 
app/app/views/products/show. html. erb where line #21 raised: 


translation missing: tl .time . formats . default 
Extracted source (around line #21): 

► 


This is becausel looks for time, formats . default for the default time and datetime format (it looks for 
date . formats . default for date). Let’s add the necessary changes 180 to our translation file as well (as some 
other entries we might need in the future): 


tl : 

date : 

formats : 

default: "%Y-%m-%d" 

short: "%b %d" 

long: "ika-%d ng %B, %Y" 

day_names: [Linggo, Lunes, Martes, Miyerkules, Huwebes, Biyernes, Sabado] 
abbr_day_names : [Lin, Lun, Mar, Mye, Huw, Bye, Sab] 

# Don't forget the nil at the beginning ; there's no such thing as a 0th month 

# Also, the line below is a single line 

month_names : [~, Enero, Pebrero, Marso, Abril, Mayo, Hunyo, Hulyo, Agosto, 
Setyembre, Oktubre, Nobyembre, Disyembre] 

abbr_month_names : [~, Ene, Peb, Mar, Abr, May, Hun, Hul, Ago, Set, Okt, Nob, Dis] 
time : 

formats : 


180 https://github.com/bryanbibat/rasm40code/commit/a7bc88e6b277f68ebad39b908891aalc398c5d4e 
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default: "ika-%d ng %B, %Y %I : %M : %S %p" 
short: "%d %b %H:%M" 
long: "ika-%d ng %B, %Y %I:%M %p" 
am: "AM" 
pm: "PM" 
views : 
button : 

create: "Likhain" 
link: 

back: "Bumalik" 
product : 
header : 

new: "Bagong Produkto" 

show: "Detalye ng Produkto" 

activerecord : 
models : 

product: "Product" 
attributes : 
product : 

name: "Pangalan" 
description: "Paglalarawan" 
cost: "Presyo" 
stock: "Dami" 

created_at: "Ginawa noong" 


The date and time formatting options can be found in the API docs under Time.strftime( ). Applying 
the changes above produces: 


1 

izi 



[<H ** C | 

© localhost:3000/products/3?locale=tl & 



Detalye ng Produkto 


Pangalan: Cola 
Paglalarawan: fizzy drink 
Presyo: $25.00 
Dami: 100 

Ginawa noong: ika-24 ng Pebrero. 2011 06:36:37 PM 
(We removed the : unit => "PhP" in preparation for the next section ) 

The other date and time formats can be specified in the 1 call. For example, if we change the created_at 
1 call to: 

<%=l @product . created_at, : format => : short %> 


We get: 
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1 

irriroi 

A 



I «- c | 

© localhost:3000/products/3?locale=tl ft 



Detalye ng Produkto 


Pangalan: Cola 
Paglalarawan: fizzy drink 
Presyo: $25.00 
Dami: 100 

Ginawa noong: 24 Peb 18:36 


Localization is not limited to time. Currency and numbers are also affected when you use the helper func- 
tions number_to_currency, number_with_del imiter, number_to_percentage, number_to_precision, and 
number_to_human_size. Note that the text in Cost no longer has a currency symbol and the scale is reduced 
to 1. Let’s fix that by adding the following entries 181 : 

tl : 

number: 
format : 

# Sets the separator between the units, for more precision (e.g. 1.0 / 2.0 == 0.5) 
separator: 

# Delimits thousands (e.g. 1,000,000 is a million) (always in groups of three) 

delimiter: 

# Number of decimals, behind the separator (1 with a precision of 2 gives: 1.00) 

precision: 3 
currency : 
format : 

# Where is the currency sign? %u is the currency unit, %n the number (default. . . 
format: "%u%n" 

unit: "PhP" 

# These three are to override number . format above and are optional 

separator: 
delimiter: 
precision: 2 

date : 


Opening the page again gives us: 


181 https://github.com/bryanbibat/rasm40code/commit/35519c0970919ellf8941b3b56753fd0d3f0ca71#diff-l 
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n 


J Q AlingnenaApp 



C [<£) k>calhost:3000/products/3?locale=t:l fa \ 


Detalye ng Produkto 


Pangalan: Cola 
Paglalarawan: fizzy drink 
Presyo: PhP25.00 
Dami: 100 

Ginawa noong: 24 Peb 18:36 
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Ruby Corner - Idioms 

New Ruby programmers might find the following line weird: 

I18n locale = params [: locale] I! session [: locale] 

This statement is equivalent to: 

if params [: locale] . ni 1 ? 

I18n. locale = session [: locale] 

else 

I18n. locale = params [: locale] 

end 

This is due to how Ruby evaluates the “or” operation; if the params [ : locale] is not nil, the evaluation 
stops and returns the value of the params [ : locale] . Otherwise, it will continue the I I evaluation and 
check sess i on [ : 1 oca 1 e ] . But regardless if sess i on [ : 1 oca 1 e ] is n i 1 or not, its value will be returned. 

Another Ruby idiom was used back in Automated Testing: 

@mock_customer ||= mock_model (Customer , stubs) . as_nul l_object 
This is roughly equivalent to: 
if §mock_customer . ni 1 ? 

§mock_customer = mock_model (Customer , stubs) . as_nul l_object 

end 

Again, this is due to the I I handling, though a slightly different one: a op= b is equivalent to a = a op 
b. In other words, the line above is also roughly equivalent to: 

@mock_customer = §mock_customer I I mock_model (Customer , stubs) . as_nul l_object 
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Deployment Options 

We’ve already discussed the different environments available in Rails so running the server in the 
production environment should be easy. All we need is to change the port number to the default HTTP 
port (80) and we should be all set: 

$ rake db: migrate RAILS_ENV=production 
$ rails server -e production -p 80 

However, there’s one big problem to this approach: Ruby, and by extension Rails and WEBrick, is 
practically single-theaded. 

Try this experiment: modify the index action of Debt to make it sleep for 30 seconds, simulating an I/O 
or processing intensive task. 

def index 

©debts = Debt. all 
sleep 30 

respond_to do I format I 

format.html # index.html .erb 
format. xml { render :xml => @debts } 

end 

end 

Then open http : //local host: 3000/debts. As expected, the page takes 30 seconds to open. 

But try opening http : //local host : 3000/products in another window while waiting for that page to 
load. You’ll see that the process is blocked. 

For years, the “industry-level” solution was to maintain a cluster of Mongrel servers (a faster alternative 
to WEBrick) and proxy the requests via a proxy server like Apache or lighttpd. 




Scaling is easy with this setup; just add additional servers and you’re done. 

Setup and maintenance, however, was not so easy. You have to configure each of the servers along with the 
proxy server. You also have to setup mechanisms to handle the rare event that some of the servers crash. 
It was as if all the ease of development in Rails was offset by the difficulty of setting up the production 


server. 
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Then came Phusion Passenger. 

Phusion Passenger 182 is a module for the industry standard Apache 183 web server and the fast and 
lightweight Nginx 184 web server. It handles the Rails process spawning as well as the proxying to these 
Rails processes. 

Basically what that means is that if you’ve got Passenger installed and configured inside your Apache or 
Nginx server, deploying your application is as simple as deploying PHP applications i.e. just upload the 
files to the server and you’re done. No need to worry about clustering or the problems that come with it. 

Installing and setting up Phusion Passenger is not included in this course. You can, however, refer to the 
documentation on the website 185 for more details. 

Asset Pipeline 

After mentioning it multiple times througout the manual, we finally get to talk about the Asset Pipeline. 

The Asset Pipeline is a framework for preprocessing assets powered by the sprockets gem. As mentioned 
before, it provides 2 main preprocessing features: 

• It allows the preprocessing of CSS and JS assets, with the most frequently used being concatenation 
and minification. 

• It fingerprints all assets CSS, JS, as well as images, audio, video, and fonts. 


To see this in action, let’s go back to the “run Rails in production mode” code in the previous section: 

$ rake db: migrate RAILS_ENV=production 
$ rails server -e production -p 80 

If you (or the trainer) tried that, you’ll see 404 errors for your JS and CSS files. This is because your app 
missed the asset compilation step. Let’s enable that now in the conf ig/environments/production . rb: 

AlingnenaApp : Application configure do 

* Settings specified here will take precedence over those in config/application.rb. 

# Do not fallback to assets pipeline if a precompiled asset is missed. 

config assets compile = true 


This will enable compiling of assets on the fly and caching it to memory. Restart your server and try again. 
You will now see the asset pipeline in action: 


182 http://www.modrails.com/ 

183 http://httpd.apache.org/ 

184 http://nginx.org/ 

185 https:/ Avww.phusionpassenger.com/ 
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< ! DOCTYPE html > 

<html> 

<head> 

<title>Al ingnenaApp</title> 

<link data-turbol inks-track="true" 

href="/assets/appl ication-8a207ac03f fb312395f89c5044da2bc5 . css" media="al 1 " 
rel="stylesheet” /> 

< script data-turbol inks- track=" true" 

src="/assets/appl ication-32646e7627bbla025ad3bdddcle385c7 . js"> </script> 

<meta content="authenticity_token" name="csr f -param" /> 

Compare this with running the app in development mode: 

<! DOCTYPE html> 

<html> 

<head> 

<title>Al ingnenaApp</title> 

<link data-turbol inks-track="true" href="/assets/appl i cat ion . css?body=l " 
media="all" rel="stylesheet" /> 

< 1 ink data-turbol inks- track=" true" href="/assets/suppl iers . css?body=l " 
media="all" rel="stylesheet" /> 

<script data-turbol inks- track=" true" src=" /assets/ j query . js?body=l "> </script> 

< script data-turbol inks- track=" true" src="/assets/appl i cat ion . js?body=l "> </script> 

In production the CSS and JS files are concatenated and minified to single files significantly reducing 
the amount of requests required to load the page. The MD5 hash is added to the file name as a 
fingerprint to get browsers to cache these assets more reliably compared to the old query string style 
(e.g. appl ication . js?135443523). 

The Asset Pipeline supports chaining of preprocessors. For example, you want to use an image asset in 
your CSS file, you can add an . erb extension to the file to give you access to helpers like asset_path. So 
instead of just, say, custom . css it will now be custom . css . erb e.g.: 

.class { background- image : url(<%= asset_path 'image. png' %> ) } 

Upon processing, the Asset Pipeline will convert it to custom. css which would probably contain 
something like: 

.class { background- image : Url(/assets/image-0d599f0ec05c3bda8c3b8a68c32alb47.png) } 

Apart from ERB, by default a new Rails application will have support for these additional file types via 
gems in the Gemf i le: 

• Sass/SCSS 186 - CSS extension languages. Sass is more concise by being whitespace dependent, while 
SCSS is an extension to CSS3, adding features but maintaining most of the look-and-feel. Both can 
be complied to CSS files e.g. custom . css . scss. 


1 86 http://sass- lang. com/ 
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• CoffeeScript 187 - A language that looks and feels like Ruby and Python, and compiles to mostly 
idiomatic JavaScript (automatically hoists variables and adds IIFE, etc). For some people, this makes 
writing good quality JS easier. Uses the . coffee extension e.g. user . js . coffee 

(By the way, the ugl i f ier gem in between the sass-rails and cof fee-rai Is gem is what Rails uses by 
default to Uglify 188 the JavaScript files.) 

With these, you can even get files like page. js. cof fee. erb. Looking at the bigger picture, though, you 
should be able to see how all this preprocessing chains lead to the Asset Pipeline being called by that term. 
Say you have an application that uses the Sass version of Bootstrap as well some other custom SCSS files: 

bootstrap . scss 

import 

bootstrap/variables. scss 
bootstrap/mixins. scss 
boot st rap/ normalize. scss 


Precompilation 

Apart from compiling the assets on the fly, Rails also supports asset precompilation. Not only does this 
save you server memory and processing power, it also allows you to offload the serving of assets to your 
web server (e.g. nginx), reverse proxy (e.g. Varnish), or even push the assets to a CDN. We can do this in 
our app now by running: 

$ rake assets : precompi le RAILS_ENV=production 

Rails will precompile the assets and place them in the public/assets folder. This would let our static 
servers (or reverse proxies) serve the files without having to run a line of Ruby code. 

Since we do not have a static server, we should tell Rails to let our application server (WEBrick) handle 
the serving of assets before we can test it out on our own. (And also disable the on-the-fly compilation 
we set earlier.) 

AlingnenaApp : App 1 i cat ion . configure do 

* Settings specified here will take precedence over those in config/application.rb. 

* Disable Rails's static asset server (Apache or nginx will already do this). 

config serve_static_assets = true 

* Do not fallback to assets pipeline if a precompiled asset is missed. 

config assets compile = false 


main . css . scss compile main. css 


page, css . scss compile page. css 


concatentate application . CSS 


Run the server in production mode now to check if your app runs fine in this precompiled asset setup. 

There are still a couple of other topics related to the Asset Pipeline like switching preprocessors and setting 
a custom asset domain, but we’ll stop the discussion at this point and leave the rest for you to explore on 
your own. 


187 http://coffeescript.org/ 

188 https://github.com/mishoo/UglifyJS 
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Rake 

Out last lesson will be a short overview on Rake, the build tool written in Ruby and used extensively by 
Rails and its plugins. 

At the heart of Rake are the rakefiles, files where you specify the processing tasks in Ruby syntax. The 
simplest way of declaring a task is using the task method. Create a rakefile named rakefile in an empty 
directory (so as not to overwrite your Rails apps) and put the following code there: 

task :first_task do 

puts "this is the first task" 

end 


Running the command “rake f irst_task” on the same folder will print out “this is the first task”. 

Like other build tools like ant, these tasks can be declared as dependent on each other so that executing one 
task will call the other required tasks. You can declare dependencies by converting the string parameter 
to the task method to a hash: 

task :first_task do 

puts "this is the first task" 

end 

task :second_task => : f irst_task do 
puts "this is the second task" 

end 

Running rake second_task here will produce: 

$ rake second_task 
(in /home/user) 
this is the first task 
this is the second task 

You can also use an array as the value of the hash to declare multiple dependencies: 

task :first_task do 

puts "this is the first task" 

end 

task :second_task do 

puts "this is the second task" 

end 

task :third_task => [ : f irst_task, : second_task] do 
puts "this is the third task" 

end 

Running rake th i rd_task will now print the three tasks. Note that when a dependency is already satisfied, 
it is no longer processed the next time another task requires it. For example: 
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task :first_task do 

puts "this is the first task" 

end 

task :second_task => : f irst_task do 
puts "this is the second task" 

end 

task :third_task => [ : f irst_task, : second_task] do 
puts "this is the third task" 

end 


Running rake third_task here would produce the same results instead of printing “this is the first task” 
twice. 

By the way, “task : third_task => [ : f irst_task, : second_task] do” is essentially shorthand for: 
task :third_task 

task :third_task => [ : f irst_task] 
task :third_task => [ : second_task] do 
task :third_task do 

end 

That is, you can add dependencies (and even processing logic) to a task even after the task is initially 
declared through anothertask call. 

Another type of task is thefile task. Instead of simply checking the dependencies, these tasks also check 
the existence and the timestamps of the specified files. For example, here’s the sample code from the Rake 
documentation for compiling 3 C files: 

file 'main. o' => ["main.c", "greet. h"] do 
sh "cc -c -o main.o main.c" 

end 

file 'greet. o' => ['greet.c'] do 
sh "cc -c -o greet. o greet.c" 

end 

file "hello" => ["main.o", "greet. o"] do 
sh "cc -o hello main.o greet. o" 

end 

On the first run of rake hello, it will first compile main.o, then greet . o, then finally the hel lo executable. 
All three files were created because they did not yet exist; going through the dependencies eventually 
created them. 

Now if you modify the main.c and run rake hello again, rake will go through the dependencies again, 
checking each for changes in the timestamp. Since main.c was changed, the file task main.o was re-run 
and the file recompiled. When Rake goes back to the hel lo file task, the main.o file changed its timestamp 
so the task is similarly re-executed. Note that since neither greet . c nor greet . o was changed since the 
last rake execution, the greet . o task was not executed again. 

You can describe tasks using the desc method on top of the task: 
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desc "prints out the first line" 

task :first_task do 

puts "this is the first task" 

end 

desc "prints out the first two lines" 

task :second_task do 

puts "this is the second task" 

end 


desc "prints out the three lines" 

task :third_task => [ : f irst_task, : second_task] do 
puts "this is the third task" 

end 


Running “rake -T” will list out the tasks with a proper desc description. 


$ rake -T 
(in /home/user) 
rake first_task 
rake second_task 
rake third_task 


# prints out the first line 

# prints out the first two lines 

# prints out the three lines 


Since desc is the standard way of documenting tasks, you can use this command to list the rake tasks for 
Rails: 


$ rake -T 


rake 

about 


rake 

assets : clean [keep] 

# 

rake 

assets : clobber 


rake 

assets : environment 


rake 

assets : precompile 

# 

rake 

cache_digests : dependencies 

# 

rake 

cache_digests : nested_dependencies 

# 

rake 

db : create 


rake 

db : drop 

# 

rake 

db : fixtures : load 

# 

rake 

db : migrate 

# 


List versions of all Rails frameworks and 
Remove old compiled assets 
Remove compiled assets 
Load asset compile environment 
Compile all the assets named in config.as 
Lookup first- level dependencies for TEMPL 
Lookup nested dependencies for TEMPLATE ( 
Create the database from DATAESASEJJRL or 
Drops the database using DATAESASEJJRL or 
Load fixtures into the current environmen 
Migrate the database (options: VERSI0N=x, 


The default task for Rake is the “default” task. Usually you just point it to another task or tasks to define 
which tasks should be run ifrake is executed without arguments. 

task : default => :third_task 

Other tasks and tips on using Rake are found at the online documentation 189 . 


189 http://rake. mbyforge.org/ 


